[RISCV64] LLD command to link libcodec2_soft_av1enc.so is taking longer than usual

[Sharjeel-Khan]

Our riscv64 buildbots started timing out because the linking step for libcodec2_soft_av1enc.so in latest AOSP release is taking longer than usual. The last good build was eac1a1d3a8dbc1f723253f642ad32c748323fafc.

Here is the reproducer: https://drive.google.com/file/d/1iSCB-JXP07-AwCvNaPuglXBT58FahEAf/view?usp=sharing

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Sharjeel Khan (Sharjeel-Khan)

Our riscv64 buildbots started timing out because the linking step for libcodec2_soft_av1enc.so in latest AOSP release is taking longer than usual. The last good build was [eac1a1d](https://github.com/llvm/llvm-project/commit/eac1a1d3a8dbc1f723253f642ad32c748323fafc).

Here is the reproducer: https://drive.google.com/file/d/1iSCB-JXP07-AwCvNaPuglXBT58FahEAf/view?usp=sharing

[Sharjeel-Khan]

I bisected this issue started from 38200e94f1428b586dc1778133120541e65c20b5.

Hey @RKSimon, can you provide some reason on why your change would cause the link command to take way longer than usual

[jrtc27]

I bisected this issue started from 38200e94f1428b586dc1778133120541e65c20b5.

Hey @RKSimon, can you provide some reason on why your change would cause the link command to take way longer than usual

That commit has no effect on LLD. Are you using LTO, which would result in CodeGen regressions only becoming visible at link time?

[Sharjeel-Khan]

Yea, we use LTO in Android

[topperc]

Best guess is that the patch is causing an infinite loop in DAGCombiner. If you run with -mllvm -opt-bisect-limit=-1 (or one of the other ways of printing which passes are running) you'll probably see that it gets stuck in SelectionDAG.

[RKSimon]

Can you provide the LTO bitcode please? You can use the guidelines here: https://www.npopov.com/2023/10/22/How-to-reduce-LLVM-crashes.html

[Sharjeel-Khan]

I ran with "-Wl,-plugin-opt=save-temps" but I never ran the command to completion so I did not know the command takes ~500 mins now. It just completed so I have temporaries now: https://drive.google.com/file/d/1Cl29E6nXOp64sc8hIICkXvDAv7kq3K8N/view?usp=sharing or https://drive.google.com/file/d/1JNJd_d3H9yj3ymWhvrR1eA2dkpRn6yBg/view?usp=sharing. I ran the commands in two different areas so I thought I could just upload both which is why there are two links (I assume they are both the same). You just need to run `tar -xzvf <name>.tar.gz" for the bitcodes. Let me know this is what you needed, @RKSimon.

[RKSimon]

I'm seeing some strange warnings:

Hard-float 'd' ABI can't be used for a target that doesn't support the D instruction set extension (ignoring target-abi)

llc: error: unable to get target for 'riscv64-unknown-linux-android10000', see --version and --triple.

Not sure how relevant they are yet - everything is really slow, but I'm expected thats down to the size of the libcodec2_soft_av1enc.so.0.5.precodegen.bc file

[Sharjeel-Khan]

You can ignore the hard-float warning (it appears many times during our builds and we ignore them).

For the second thing, it is the target we use in our buildbots. It might be the generic clang does not recognize it but Android toolchain's clang does. It just helps clang figure out which builtins, libraries, and runtimes to use. The lld reproducer above might have a few of those things.

[RKSimon]

I haven't been able to reduce this but having left it running in the debugger for a while, it seems to be stuck handling frozen RISCVISD::SELECT_CC nodes - whats odd is that its a long chain of them - each RISCVISD::SELECT_CC node having (potentially frozen) RISCVISD::SELECT_CC nodes as one/both of their TRUE/FALSE operands.

@topperc any insight on what could be happening here?