[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 https://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?)