Open Quuxplusone opened 3 years ago
Attached AVR.llvm13
(27409 bytes, text/plain): -ftime report output
FWIW, if I omit clang-tools-extra from the list of projects to build (i.e.
restrict
it to clang;compiler-rt;polly, a 2-stage build with -
DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=OFF
completes.
Besides, there are some test result differences with and without the new PM:
-Failed Tests (75):
+Failed Tests (72):
+ LLVM-Unit :: BinaryFormat/./BinaryFormatTests/MachOTest.UnalignedLC
LLVM :: Bindings/Go/go.test
- LLVM :: CodeGen/X86/known-signbits-vector.ll
- LLVM :: CodeGen/X86/vec_shift5.ll
- LLVM :: CodeGen/X86/vector-shift-ashr-128.ll
- LLVM :: CodeGen/X86/vector-shift-ashr-256.ll
Could you attach -ftime-trace?
Also, is your clang compiled with asserts on? If so have you synced to https://reviews.llvm.org/D97225, which disables some checks that can take a long time?
Attached AVR.json.bz2
(67284 bytes, application/x-bzip): -ftime-trace output
(In reply to Arthur Eubanks from comment #2)
> Could you attach -ftime-trace?
Sure, done.
> Also, is your clang compiled with asserts on? If so have you synced to
It is, to match what the buildbots use.
> https://reviews.llvm.org/D97225, which disables some checks that can take a
> long time?
I had indeed.
Ok so it's not related to those checks then.
If I'm reading the time trace right (loadable via chrome://tracing), it seems to show that isel is taking a long time, rather than any specific middle-end pass.
If I had to guess, SPARC isel has really bad runtimes on specific inputs, e.g. large functions. The new PM has a different inliner and can cause some functions to be large. You can check the LLVM IR to see if any functions are much larger with the legacy PM vs the new PM (clang++ -Xclang -disable-llvm-passes -emit-llvm -S). So I don't think this is a new PM issue, merely that it exposes an issue with SPARC isel. Adding people who have worked on that would be good.
And now I see that I missed the instruction selection section in the initial -ftime-report that showed this.
(In reply to Arthur Eubanks from comment #5)
> If I had to guess, SPARC isel has really bad runtimes on specific inputs,
> e.g. large functions. The new PM has a different inliner and can cause some
> functions to be large. You can check the LLVM IR to see if any functions are
> much larger with the legacy PM vs the new PM (clang++ -Xclang
> -disable-llvm-passes -emit-llvm -S). So I don't think this is a new PM
I tried this, but AVR.ll is identical without and with the new PM.
> issue, merely that it exposes an issue with SPARC isel. Adding people who
> have worked on that would be good.
That might be hard, unfortunately: many changes to the Sparc backend have been
purely mechanical recently. I'm trying Jessica, but two others don't even have
a bugzilla account, unfortunately (LemonBoy <thatlemon@gmail.com> and Daniel
Cederman <cederman@gaisler.com>).
Sorry, I didn't mean to add -Xclang -disable-llvm-passes
to the command line, that disables running any passes at all on the output of clang.
It should be clang++ -S -emit-llvm -flegacy-pass-manager
vs clang++ -S -emit-llvm -fno-legacy-pass-manager
.
There should be a difference there.
AVR.llvm13
(27409 bytes, text/plain)AVR.json.bz2
(67284 bytes, application/x-bzip)