[zmodem]

LLVM has been refactoring how it stores its internal (-mllvm) options recently, with the goal of getting rid of the global cl::opt objects.

After http://github.com/llvm/llvm-project/pull/233044 LTO passes no longer uses the global options, which would cause codegen-llvm/pgo-counter-bias.rs to fail since it relies on the -runtime-counter-relocation option to get passed to LTO.

IIUC, ideally we should change LLVMRustSetLLVMOptions to take an LLVMContext as argument and parse the options into that. However, I think by the time we currently call it, no such context has been created yet.

Instead, this PR maintains the status quo by parsing the options into a global object, which is then assigned to new LLVMContexts as they are created.

[rustbot]

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @cuviper

[zmodem]

@rustbot label llvm-main

[zmodem]

r? @nikic

[nikic]

@MaskRay I'm curious how LibraryOptions is supposed to be adopted incrementally. Ideally, we would be parsing the options per-context -- but while not all options are per-context, the ones which are not would get parsed globally multiple times. That's not (thread) safe, right?

So does that mean that until the global options are entirely gone, we should basically keep using a global LibraryOptions, rather than a per-context (and thus per-thread) one? (That is, do what this PR does?)

[durin42]

I rebased this patch so the LLVM/Rust @Head CI can keep passing.

[nikic]

Now that llvm/llvm-project#234820 has landed, I wonder if some parts of this have become unnecessary?

I think things would mostly "just work" if we used the C API for option parsing?

View changes since this review

[zmodem]

I think things would mostly "just work" if we used the C API for option parsing?

Yes, I think so too. Let's close this.

[zmodem]

Hmm no, tests/codegen-llvm/pgo-counter-bias.rs still fails without this. I must have had the wrong branch checked out when I tested locally.

I'll start by rebasing this.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[zmodem]

I tried switching to LLVMParseCommandLineOptions instead of cl::ParseCommandLineOptions, but that causes tests/ui/codegen/llvm-args-invalid-flag.rs to break since it expects an error message on stderr, and the C API function eats it.

[nikic]

I tried switching to LLVMParseCommandLineOptions instead of cl::ParseCommandLineOptions, but that causes tests/ui/codegen/llvm-args-invalid-flag.rs to break since it expects an error message on stderr, and the C API function eats it.

I think if error reporting is the only issue, we should probably add an LLVMParseCommandLineOptionsWithError binding that also provides the error message as a string, and then use that in Rust.

[zmodem]

Sent llvm/llvm-project#238461