Build failure with LLVM ERROR on `sparc-unknown-linux-gnu`

[JohnTitor]

The libc build with cargo's build-std fails due to:

2020-10-27T12:22:33.1169362Z LLVM ERROR: unable to allocate function return #6
2020-10-27T12:22:33.1212572Z error: could not compile `compiler_builtins`

(Here's the log: https://github.com/rust-lang/libc/runs/1314551399)

I recently updated compiler_builtins to 0.1.36 (rust-lang/rust#78209) on rust-lang/rust and turned out that's the cause.
We can reproduce the failure with cargo build -Z build-std=core,alloc -vv --target sparc-unknown-linux-gnu on this repo as well.

[parraman]

I'm experiencing the same error. Does anybody know what can be causing it?

[parraman]

I believe I have found the source of the problem. The thing is that the rust compiler/LLVM Sparc backend is unable to lower a function that takes two 128-bit unsigned integers as arguments and returns a tuple with two 128-bit unsigned integers. The following function causes the same error:

fn test_128(one: u128, two: u128) -> (u128, u128) {
    let division = one / two;
    (division + 40000000, division - 100000)
}

One possible solution could be to disable the generation of the 128-bit division altogether by using a feature. Another solution could be to implement a new macro that only returns one single 128-bit integer: either the quotient or the reminder.

cc: @AaronKutch

[AaronKutch]

I'm guessing that some algorithm in the Sparc backend responsible for putting large arguments on the stack is failing? I'm looking for any fixes for the root problem so I don't have to put hacks in my beautiful function setup.

[AaronKutch]

If the problem is deep in LLVM, then I think the best decision is for me to add one more feature flag that turns on a simple no-subalgorithm binary division algorithm path that would fix it.

[parraman]

I think that's the best solution for now. I don't know how hard it would be to fix the problem in the implementation of LLVM for Sparc. I believe it has something to do with the definition of the Calling Convention, but my experience with LLVM at that level is basically non-existent.

Thanks a lot!

[AaronKutch]

I realized that both 32-bit and 64-bit SPARC do not have widening multiplications (and in fact I think it is the only 64-bit target without widening multiplication), which makes the default division chain I am using inefficient for all SPARCs. I have decided upon using configuration and not feature flags to enable a specialized path for SPARC that also doesn't use (u128, u128) returns.

target_arch = "sparc64" seems to match against both the sparc64 and sparcv9 targets I can access from rustup target list. However, I cannot easily test any 32-bit SPARC targets, so can someone with a sparc-unknown-linux-gnu target test if #[cfg(target_arch = "sparc")] is enabled? Also, can you run rustc --target=sparc-unknown-linux-gnu --print=target-features and comment with the output?

[parraman]

I can help you with testing a 32-bit SPARC target since that's precisely what I am using. I can confirm you that #[cfg(target_arch = "sparc")]is enabled.

This is the output for the command you requested:

Available features for this target:
    deprecated-v8     - Enable deprecated V8 instructions in V9 mode.
    detectroundchange - LEON3 erratum detection: Detects any rounding mode change request: use only the round-to-nearest rounding mode.
    fixallfdivsqrt    - LEON erratum fix: Fix FDIVS/FDIVD/FSQRTS/FSQRTD instructions with NOPs and floating-point store.
    hard-quad-float   - Enable quad-word floating point instructions.
    hasleoncasa       - Enable CASA instruction for LEON3 and LEON4 processors.
    hasumacsmac       - Enable UMAC and SMAC for LEON3 and LEON4 processors.
    insertnopload     - LEON3 erratum fix: Insert a NOP instruction after every single-cycle load instruction when the next instruction is another load/store instruction.
    leon              - Enable LEON extensions.
    leoncyclecounter  - Use the Leon cycle counter register.
    leonpwrpsr        - Enable the PWRPSR instruction.
    no-fmuls          - Disable the fmuls instruction..
    no-fsmuld         - Disable the fsmuld instruction..
    popc              - Use the popc (population count) instruction.
    soft-float        - Use software emulation for floating point.
    soft-mul-div      - Use software emulation for integer multiply and divide.
    v9                - Enable SPARC-V9 instructions.
    vis               - Enable UltraSPARC Visual Instruction Set extensions.
    vis2              - Enable Visual Instruction Set extensions II.
    vis3              - Enable Visual Instruction Set extensions III.

Rust-specific features:
    crt-static        - Enables libraries with C Run-time Libraries(CRT) to be statically linked.

Thanks!!

[AaronKutch]

Thanks. I have a PR up that should fix the issue. Can you try out the branch locally to see if it is fixed, because the CI will not catch your problem?

[AaronKutch]

wait the CI is catching some problem, let me fix it

[AaronKutch]

It looks like the CI is broken for some other reason, can you try out the fixes anyway?

[parraman]

I have checked out the PR and it compiles. I haven't tried it though because basically, I don't know how to do it.

I cannot use it in my current projects because the cargo build command automatically downloads the compiler_builtins package and compiles together with my project. If the version that it downloads is the current one (i.e. 1.36), it crashes and if I set for it to download a previous version, then it enters in conflict with your package. I can only tell it which nightly version it shall use to compile the project. The last one that it works is nightly-2020-10-25 since it is the last one that uses version 1.35.

What can I do to try it?

[AaronKutch]

I just adjusted the PR. I'm not sure how to fix your problem, because I don't know what specific build process you are using to inject compiler-builtins, maybe there is a Cargo.toml somewhere that you can change from compiler_builtins = "1.36" to compiler_builtins = {git = "https://github.com/AaronKutch/compiler-builtins", branch = "sparc-division"}.

[parraman]

The package is included automatically into the compilation process. I am using a feature called build-std, which is an unstable feature that makes cargo compile parts of the std (such as core or alloc) together with your project for targets that are not fully supported. Apparently, it uses the latest version of compiler-builtins available and, as far as I know, it cannot be tailored. If I add the dependency as you describe in my Cargo.toml, it basically includes it together with the version that is attached to the version of std that I am currently using :-(