It'd be absolutely fantastic if Rust would use LLVM from Ports, instead of compiling an own copy. Everyone using Poudriere to build stuff would benefit from it.

Last time I asked about this people mentioned this:
https://github.com/rust-lang/rust/issues/49653

In D32654#737489, @diizzy wrote:

Last time I asked about this people mentioned this:
https://github.com/rust-lang/rust/issues/49653

Note, I am not a Rust developer, but this is how I understand this:

1. "--print target-{cpus,features}": prints LLVM target feature(s).
2. "-C target-{cpu,feature}": passes target feature(s) to LLVM backend.
3. "#[target_feature]": guards by supported CPU features, e.g.: https://rust-lang.github.io/rfcs/2045-target-feature.html#unconditional-code-generation-target_feature.

"[rust] Add accessors for MCSubtargetInfo CPU and Feature tables":

$ rg 'getFeatureTable'
src/llvm-project/llvm/include/llvm/MC/MCSubtargetInfo.h
236: ArrayRef<SubtargetFeatureKV> getFeatureTable() const {

compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp
416: const ArrayRef<SubtargetFeatureKV> FeatTable = MCInfo->getFeatureTable();
424: const ArrayRef<SubtargetFeatureKV> FeatTable = MCInfo->getFeatureTable();

PassWrapper.cpp, guarded by #ifdef LLVM_RUSTLLVM e.g.:

extern "C" void LLVMRustGetTargetFeature(LLVMTargetMachineRef TM, size_t Index,

                                       const char** Feature, const char** Desc) {
[...]
const ArrayRef<SubtargetFeatureKV> FeatTable = MCInfo->getFeatureTable();
const SubtargetFeatureKV Feat = FeatTable[Index];
*Feature = Feat.Key;
*Desc = Feat.Desc;

}

$ rg 'LLVMRustGetTargetFeature'

compiler/rustc_codegen_llvm/src/llvm_util.rs
229: let len = unsafe { llvm::LLVMRustGetTargetFeaturesCount(tm) };
235: llvm::LLVMRustGetTargetFeature(tm, i, &mut feature, &mut desc);

compiler/rustc_codegen_llvm/src/llvm/ffi.rs (FFI interface)
2136: pub fn LLVMRustGetTargetFeaturesCount(T: &TargetMachine) -> size_t;
2137: pub fn LLVMRustGetTargetFeature(

llvm_util.rs, e.g.:

llvm_target_features(tm: &llvm::TargetMachine) -> Vec<(&str, &str)>
[...]

llvm::LLVMRustGetTargetFeature(tm, i, &mut feature, &mut desc);
if feature.is_null() || desc.is_null() {
    bug!("LLVM returned a `null` target feature string");
}
let feature = CStr::from_ptr(feature).to_str().unwrap_or_else(|e| {
    bug!("LLVM returned a non-utf8 feature string: {}", e);
});
let desc = CStr::from_ptr(desc).to_str().unwrap_or_else(|e| {
    bug!("LLVM returned a non-utf8 feature string: {}", e);
});

[...]

$ rg 'llvm_target_features'

compiler/rustc_codegen_llvm/src/llvm_util.rs
228:fn llvm_target_features(tm: &llvm::TargetMachine) -> Vec<(&str, &str)> {
252: let mut target_features = llvm_target_features(tm);

llvm_util.rs:

fn print_target_features(sess: &Session, tm: &llvm::TargetMachine) {

let mut target_features = llvm_target_features(tm);

[...]

println!("Features supported by rustc for this target:");
for (feature, desc) in &rustc_target_features {
    println!("    {1:0$} - {2}.", max_feature_len, feature, desc);
}

[...]

The sole user of getFeatureTable() of Rust's LLVM fork is rustc target
feature printer (help). Repeating the same to trace getCPUTable() use
is not necessary because the only getCPUTable() call is guarded
with LLVM_RUSTLLVM.

2. and 3. is tedious to trace, but likely not needed since Rust's LLVM fork

does not maintain related patches, and target_feature was switched from getFeatureTable
and LLVM_RUSTLLVM on LLVM 6+ [1]. Note, upstream has issues with non-stable rustc/LLVM
mapping [2], but SIMD for amd64 is stabilized [3][4].

[1]: https://github.com/rust-lang/rust/pull/49428
[2]: https://github.com/rust-lang/rust/pull/84004#issue-853651627
[3]: https://github.com/rust-lang/rust/blob/69e1d22ddbc6/compiler/rustc_codegen_ssa/src/target_features.rs#L54
[4]: https://github.com/rust-lang/rust/pull/49664

Also, -C target-cpu=skylake SIMD codegen here:
https://gist.github.com/mmatyas/639fc151dda34bb6dd07ee28120677a5

$ rustc -C target-cpu=skylake --emit asm mat4.rs
$ rg 'vmovss' mat4.s
[...]
vmovss %xmm0, 8(%rsp)
[...]

What I am concerned with:

If LLVM doesn't maintain ABI compatibility per major release (I don't know),
then lang/rust with PORT_LLVM will need a rebuild for each ABI breakage in a
minor release. LLVM soname versioning depends on LLVM_MAJOR (e.g. so.12 and so.13),
so I guess ABI compatibility during a major release is more likely to be than not.

Technical issues aside: Is there a committer who is going to own/support this?

In D32654#739293, @tobik wrote:

Technical issues aside: Is there a committer who is going to own/support this?

Not me.

Is there a committer who is going to own/support this?

Is being a committer a hard requirement?

I am interested to use this as long as I use FreeBSD, and plan to fix possible
breakage as I can. And I'm not the only one that can do this, FreeBSD is likely a community project.

PORT_LLVM was a non-default option for years before removal, and it wasn't always
QA'ed according to git log --grep='PORT_LLVM'.

Besides, I marked this as "experimental" to avoid implying maintainance burden.

Also, why aren't you interested? PORT_LLVM benefits are:

• Faster patch testing and bisection.
• Tier-2/3 machines with no package builders e.g. RISC-V can benefit from faster lang/rust builds, including the initial bring-up work.
• Binary packages aren't always an option, and PORT_LLVM helps when:
  • poudriere-devel pkg seeding doesn't fetch on dependency mismatch e.g. after ca_root_nss or curl updates when project builders can't catch up for days.
  • The above also applies for port maintainers building ports which dependency graph includes lang/rust, resulting in a lang/rust build for each jail, e.g. every supported release sometimes combined with i386.

One would rather avoid building bundled LLVM when ports LLVM was already built.

I get faster lang/rust build time with PORT_LLVM=on (~36 min. vs ~20 min. with on).
The impact might be more noticeable on slower machines like riscv64 boards.

In D32654#742356, @tobik wrote:

Just put "unsupported" after the option description. Let's hope somebody supports it once it's in. Some of the interested committers in here can commit it.

Unsupported might be understood as "not working". At least, that's what I would thought. Maybe "experimental"?

I mean just use "community supported" then?

Anyway use your own judgement. I'm not insisting on it.

In D32654#742309, @evgeniy_khramtsov.org wrote:

Is there a committer who is going to own/support this?

I am interested to use this as long as I use FreeBSD, and plan to fix possible
breakage as I can. And I'm not the only one that can do this, FreeBSD is likely a community project.

I need to warn that now I have no time for FOSS at all until somewhere in 2022Q2-2022Q3. I stopped
updating beyond security fixes, and I no longer do local QA against unmodified base and ports. If anyone
interested commits this, you likely can't expect help from me until somewhere in 2022Q2-2022Q3.

Commit message was lost and I have yet to learn to use Phabricator beyond Web frontend:

From: Evgeniy Khramtsov <evgeniy@khramtsov.org>
Date: Tue, 5 Jul 2022 09:32:14 +0000
Subject: [PATCH] lang/rust: allow experimental static linking against
LLVM from ports

Rust bundles vendored LLVM for rarely essential changes,
or features guarded behind LLVM_RUSTLLVM, that may not
be required for a user.

Upstream also provides a way to link against external LLVM,
which can save build time when devel/llvmN was already built.

Provide experimental tunable "LLVM_PORT" to allow building
against LLVM from the FreeBSD ports collection. This tunable
is unsupported and its use is discouraged.

Inspired by:            Gentoo
Reviewed by:            tobik
Differential Revision:  https://reviews.freebsd.org/D32654

---

Intermediate commit messages are not kept even when using arcinator (phab's command line interface), you have to explicitly put them in the comment/summary section

In D32654#810083, @evgeniy_khramtsov.org wrote:

Commit message was lost and I have yet to learn to use Phabricator beyond Web frontend:

From: Evgeniy Khramtsov <evgeniy@khramtsov.org>
Date: Tue, 5 Jul 2022 09:32:14 +0000
Subject: [PATCH] lang/rust: allow experimental static linking against
LLVM from ports

Rust bundles vendored LLVM for rarely essential changes,
or features guarded behind LLVM_RUSTLLVM, that may not
be required for a user.
---

does these statements come from the rust project or is it your personal opinion?

Rust bundles vendored LLVM for rarely essential changes,
or features guarded behind LLVM_RUSTLLVM, that may not
be required for a user.
---

does these statements come from the rust project or is it your personal opinion?

Obviously, not from www.rust-lang.org. Feel free to reword.
I don't see anything essential in Rust's fork https://github.com/rust-lang/llvm-project/commits/rustc/14.0-2022-06-20 to build ports on FreeBSD.

This is Rust's documentation regarding updating and fixing bugs in their LLVM: https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html

What's the real life approach with this change? Are we going to stick to using default version in ports tree of LLVM? If doable is that supported by upstream and if not who is going to take care of fallouts? If not, are we going to track upstream instead and is it worth the effort of unbundling LLVM as there like will be a handful of ports depending on the same (recent) version of LLVM?

In D32654#960813, @diizzy wrote:

What's the real life approach with this change?

Saving cycles by using an external LLVM rather than compiling the entire bundled copy.

Are we going to stick to using default version in ports tree of LLVM?

The bundled LLVM remains the default option, this is merely a use-at-own-risk convenience for those who want/have to build themselves.

If doable is that supported by upstream and if not who is going to take care of fallouts? If not, are we going to track upstream instead and is it worth the effort of unbundling LLVM as there like will be a handful of ports depending on the same (recent) version of LLVM?

The situation has changed drastically when this option was removed. Back then, which was during the LLVM 6.0/7.0 era, rust tracked LLVM trunk and was thus more sensitive to interactions between them, as evidenced with the small API breakage that eventually lead to the option removal. Starting with LLVM 8.0 and the advent of llvm-wrapper, rust switched to tracking releases with cherry-picking existing bug fix commits, much like we do with our base LLVM. Concurrently and consequently, external LLVM support has improved, with upstream tracking which LLVM version ranges work with each rust release.