rustc needs sensible options for the emission of LLVM IR/LLVM bitcode/ASM

[chris-morgan]

At present,

• rustc foo.rs emits a binary;
• rustc --emit-llvm foo.rs emits LLVM bitcode;
• rustc -S foo.rs emits the final Assembler code;
• rustc --emit-llvm -S foo.rs emits LLVM IR.

This is madness!

Here is my desired behaviour:

• rustc --emit-binary foo.rs emits a binary;
• rustc --emit-llvm-bc foo.rs emits LLVM bitcode;
• rustc --emit-asm foo.rs emits the final Assembler code;
• rustc --emit-llvm-ir foo.rs emits LLVM IR.

More than one of these options may be specified, in which case multiple things would be built; if no --emit-* option is specified, it will of course default to --emit-binary.

A brief look at the code suggests that at present it is only designed to produce one of these. An alternative, if staying within this constraint, would be --emit=(binary|llvm-(bc|ir)|asm); however, I feel allowing multiple outputs would be nicer, though I guess just -o wouldn't cut it.

[huonw]

Allowing multiple --emit=foo arguments might also work, and provides a natural grouping for documentation purposes, e.g. rustc --emit=binary --emit=asm my-file.rs and/or rustc --emit=binary,asm my-file.rs.

[chris-morgan]

@huonw When I was thrashing the idea out in #rust last night I considered both those forms, but decided --emit-* to be nicer than --emit=* if only one is supported. The latter option, --emit=binary,asm, is much of a muchness with --emit-binary --emit-asm, I feel.

[basic-calculus]

I would support having --emit=binary,asm because then arguments later on could override previous arguments which is useful for makefiles. For example, suppose one had a makefile that had a RUST_FLAGS parameter, and invokes rustc as rustc --emit=binary mycrate.rs $(RUST_FLAGS). Then one could set RUST_FLAGS to --emit=asm, and only get assembler code produced, and not have the binary code produced. One problem that I still have not figured out is how the names of the outputs could be specified.

[chris-morgan]

@sstewartgallus assuming a default of --emit=binary (the only sensible default, of course), one would not be expected to ever actually provide --emit=binary as in your example.

How this fits in with -o is also an interesting question.

[emberian]

Concrete proposal:

--emit={bin,lib,rlib,asm,ir,bc}

Merges --rlib/--lib/--bin into it. -o will only be able to be provided if only one emit is given. Alternatively, could have --emit bin=foo,lib=foo.so,rlib=foo.rlib,asm=foo.s,ir=foo.ll,bc=foo.bc and control it that way.

@alexcrichton?

[alexcrichton]

I do like the idea of consolidating what is now like 8 flags into one, although there's one complication that I can think of. Currently the lib/bin distinction affects codegen in terms of visibility of functions, so with --emit you don't necessarily have a method of saying "output the library IR and output the executable IR".

I suppose we could default to "output the library IR", but if you're debugging IR for reachability optimizations you may not want that. I think I'd be ok with this as the default.

I do like the idea of one --emit though, and I think that the comma-separated list of type[=dest] is a good idea as well. I think that -o will definitely "just fall into place" after this is done.

Nominating, I'm mostly a fan of this proposal and if we're doing this for 1.0 we need to remove the existing flags sooner rather than later.

[emberian]

Hm. Let's take a hint from ad-hoc URL protocol composition! --emit rlib+ir=foo.ll The valid LHS of + are bin,lib,rlib, the valid RHS are
ir,asm,bc.

[huonw]

What about: --crate-type=rlib,lib,bin,... and --emit=asm,ir,... rather than trying to merge the two in an ad-hoc way.

[alexcrichton]

This just gets more and more appealing!

--crate-type=rlib,lib,bin,staticlib,dylib
--emit=asm,bc,ir,obj,<xx>

That's the full and complete list I can think of, although <xx> is the name of "just finish compilation and output that", but I'm not sure of a good name for that (obj is foo.o)

[emberian]

<xx> could be final, complete, or maybe linked.

[pnkfelix]

Can we keep -S on its own as a shorthand for whatever the long option is for emitting the final Assembler code? Its a reasonably standard convention for native code compilers, no?

[brson]

we should also consider compatibility with clang's flags

[pnkfelix]

accepted for first major release, P-back-compat-libs

[emberian]

I don't really like maintaining cli flag compatibility with other compilers. It seems incredibly unimportant, since we're not aiming to be a drop-in replacement for any compiler (unlike clang/icc which aim to emulate gcc)