compiling for msp430 doesn't work with multiple codegen units

[japaric]

Background: For this target the LLVM backend doesn't support producing object files so we do something slightly different: rustc uses LLVM to produce an assembly file for each crate, then it calls msp430-elf-gcc to assemble that file into an object file and makes an rlib out of that.

With multiple codegen units we don't quite do the right thing right now because rustc produces N assembly files and then tries to create a single object file, with the wrong file path:

$ cp -r $(rustc --print sysroot)/lib/rustlib/src/rust/src/libcore .

$ cd libcore

# with 32 codegen units
$ cargo build --target msp430-none-elf
   Compiling core v0.0.0 (file:///home/japaric/tmp/libcore)
error: linking with `msp430-elf-gcc` failed: exit code: 1
  |
  = note: "msp430-elf-gcc" "-mcpu=msp430" "-c" "-o" "/home/japaric/tmp/libcore/target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.o" "/home/japaric/tmp/libcore/target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.s"
  = note: msp430-elf-gcc: error: /home/japaric/tmp/libcore/target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.s: No such file or directory
          msp430-elf-gcc: fatal error: no input files
          compilation terminated.

$ ls target/msp430-none-elf/debug/deps/*.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.0.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.10.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.11.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.12.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.13.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.14.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.15.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.16.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.17.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.18.s
target/msp430-none-elf/debug/deps/core-bac07e1e86186fd7.19.s
(..)

To support multiple codegen units rustc would have to invoke gcc once per assembly file. Which means calling it 32 times in this case. Thus increasing codegen units with this target is likely to slow down the build process.

Alex suggested tweaking this particular target to use a single codegen unit; at least until the LLVM backend learns how to generate object files.

cc @alexcrichton @pftbest

[japaric]

Alex suggested tweaking this particular target to use a single codegen unit

(#44853 changed the default number of codegen units to 32 when compiling without optimizations)

[japaric]

#44853 changed the default number of codegen units to 32

This change probably also broke the NVPTX target (haven't checked yet). If that's the case we should also change the number of codegen units for that target to 1.

[pftbest]

This target has a very small memory size, so the programs for this target are usually small and don't suffer much from slow compilation time.