Stream: t-compiler/major changes

Topic: Rename -Cllvm-args to something backend a… compiler-team#421

triagebot (Mar 25 2021 at 10:39, on Zulip):

A new proposal has been announced: Rename -Cllvm-args to something backend agnostic #421. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

bjorn3 (Mar 25 2021 at 10:44, on Zulip):

I prefer the name -Cbackend-args. codegen args is already the (internal) name for the whole -C family.

bjorn3 (Mar 25 2021 at 10:45, on Zulip):

It did be nice if -Cbackend-args would support being passed multiple times with the args being concattenated.

bjorn3 (Mar 25 2021 at 10:47, on Zulip):

Maybe it should also require passing the backend name again to either ignore or error when a different backend is used? It could be something like "-Cbackend-args=llvm:arg1 arg2".

XAMPPRocky (Mar 25 2021 at 11:02, on Zulip):

I mean I'm definitely in favour of a smarter version of the flag, but I'd be happy with it as is, just with a different name.

Not sure if requiring the name be passed in would be worth it though unless we'd want people to support multiple backends by always passing all of the arguments for all of the backends they support e.g. -Cbackend-args="llvm:--help cranelift:--help".

XAMPPRocky (Mar 25 2021 at 12:34, on Zulip):

Oh wait I see what you meant now. Hmm, maybe that is useful. Though maybe having as its own flag makes more sense like -Cbackend-flavor=cranelift so that it could apply to other things and then -Cllvm-args could expand to just -Cbackend-args="..." -Cbackend-flavor=llvm.

bjorn3 (Mar 25 2021 at 12:37, on Zulip):

We already have -Zcodegen-backend=llvm/cranelift. I was concerned about the case where someone uses RUSTFLAGS to pass one of -Zcodegen-backend or -Cbackend-args and .cargo/config.toml (or a profile in Cargo.toml) for the other flag. In that case you may accidentally end up with a mismatch between expected and actual codegen backend.

comex (Mar 25 2021 at 20:45, on Zulip):

I think “llvm” should be at least somewhere in the argument - if not in the argument name, then as part of the value like @bjorn3 suggested. The options exposed by llvm-args tend to be very low level and implementation specific, so I wouldn’t expect any other backends to have compatibility with them, now or in the future. As such, it’s good for the compiler to know that the user is trying to pass arguments to LLVM, so it can produce a proper error if a different codegen backend is in use, rather than having that backend complain that the flags are unrecognized.

comex (Mar 25 2021 at 20:50, on Zulip):

Also, I could imagine rustc someday supporting using multiple backends for different functions in the same crate. (You might want to prioritize runtime performance for some functions and compile time for others.) In that case, there would need to be a way to specify options for each backend, which also benefits from naming the backend as part of the argument.

comex (Mar 25 2021 at 20:53, on Zulip):

However, if the backend name is part of the argument, using -Cbackend-args=llvm:arg instead of -Cllvm-args=arg feels to me like it’s more verbose for no reason. Why not just keep -Cllvm-args but change it to only work for LLVM, and add -Ccranelift-args for Cranelift?

bjorn3 (Mar 25 2021 at 20:54, on Zulip):

That would require hard-coding all possible backends in rustc as by the time the codegen backend to use is determined, all arguments have already been parsed.

nagisa (Mar 25 2021 at 20:55, on Zulip):

We already have a number of arguments that have 2 levels (--extern=crate=path for example)

comex (Mar 25 2021 at 20:57, on Zulip):

@bjorn3 Is that such a big deal?

comex (Mar 25 2021 at 20:57, on Zulip):

@nagisa True; on the other hand, -Cllvm-args already exists and adding a new syntax would be not-strictly-necessary churn.

nagisa (Mar 25 2021 at 20:57, on Zulip):

there are already a number of out-of-tree backends.

bjorn3 (Mar 25 2021 at 20:58, on Zulip):

The list of possible backends is potentially infinite. In addition how would an unofficial codegen backend be handled? Adding a -C...-args would make it look official and the backend may end up getting abandoned.

nagisa (Mar 25 2021 at 20:58, on Zulip):

-Cllvm-args doesn't need to be deprecated or removed IMO, it can be transparently rewritten to -Ccodegen-args=llvm=... or similar.

nagisa (Mar 25 2021 at 20:59, on Zulip):

(My vote is on -Ccg-args or -Ccodegen-args)

XAMPPRocky (Mar 29 2021 at 16:55, on Zulip):

The problem with -Ccodegen-args in my opinion is that -C flags are already called codegen arguments. So this would be the ‘“codegen arguments” codegen argument’, which is why my preference is for something like backend-args or something that has some other distinguishing word than codegen.

cuviper (Mar 29 2021 at 17:11, on Zulip):

-Cbackend-args sounds like a good match for -Zcodegen-backend, especially if the latter is stabilized as -Cbackend

triagebot (Apr 15 2021 at 14:07, on Zulip):

@T-compiler: Proposal #421 has been seconded, and will be approved in 10 days if no objections are raised.

Nikita Popov (Apr 15 2021 at 20:40, on Zulip):

Would it be possible to approach this the other way around, and let the codegen backend deal with all flags under a common prefix? That is -C llvm-* and -C cranelift-*. -C llvm-args is by far not the only LLVM-specific option we have, and it would be a shame if it would be necessary to shove all codegen backend specific configuration under a single flag.

cuviper (Apr 15 2021 at 21:41, on Zulip):

are the possible backends a hard-coded list? I don't think it would be good if that has to be open to arbitrary names

nagisa (Apr 15 2021 at 21:45, on Zulip):

No, can have arbitrary backend a out of tree too.

pnkfelix (Apr 16 2021 at 01:22, on Zulip):

another option would be to keep -Cllvm-args but also add -Cbackend-args … i.e. truly LLVM specific stuff would continue to be fed via -Cllvm-args, while flags that are generic enough to be shared across backends would be lifted to -Cbackend-args ...

pnkfelix (Apr 16 2021 at 01:23, on Zulip):

(or is there some way that you expect to specify LLVM-specific stuff in the -Cbackend-args list?, in a manner that gets automatically filtered somehow?)

simulacrum (Apr 16 2021 at 01:55, on Zulip):

I wonder if we should be supporting random arguments without filtering of some kind, I guess maybe the ship has sailed with LLVM at least... but it seems like a clear stability hole, right? We just get away with it because few people set these options.

bjorn3 (Apr 16 2021 at 09:08, on Zulip):

pnkfelix said:

another option would be to keep -Cllvm-args but also add -Cbackend-args … i.e. truly LLVM specific stuff would continue to be fed via -Cllvm-args, while flags that are generic enough to be shared across backends would be lifted to -Cbackend-args ...

For cg_clif I put a couple of flags that will only be supported by cg_clif behind -Cllvm-args like "codegen-mode" which allows chosing between AOT compilation and various JIT modes.

bjorn3 (Apr 16 2021 at 09:08, on Zulip):

I am fine with putting everything behind -Zunstable-features.

triagebot (May 06 2021 at 17:24, on Zulip):

This proposal has been accepted: #421.

Last update: May 07 2021 at 08:00UTC