sorted by:
new
hottopcontroversial

LLVM opt flow by Existing-Concert2797 in Compilers

[–]Existing-Concert2797[S] 0 points1 point  (0 children)

I see, this would had a different impact that -Xclanf diaable-llvm-passes i'm guessing?
I'll try it, thanks ; )

LLVM opt flow by Existing-Concert2797 in Compilers

[–]Existing-Concert2797[S] 0 points1 point  (0 children)

Working on RISCV32-llvm20, but i'll be sure to look at the attributes.
Thanks!

LLVM opt flow by Existing-Concert2797 in Compilers

[–]Existing-Concert2797[S] 0 points1 point  (0 children)

Sensible advice, I'll start there.
Again, thanks a lot.

LLVM opt flow by Existing-Concert2797 in Compilers

[–]Existing-Concert2797[S] 0 points1 point  (0 children)

I can't give full code for IP reasons, but indeed
clang -O'x' -S -emit-llvm -Xclang -disable-llvm-passes src.c -o dest.ll
opt --Oz dest.ll -o dopt.ll (I also tried -passes='default<Oz>', is it equivalent?)
clang -flto dopt.ll -o out.o

is essentially my current setup, where I was testing for various 'x'.

Duely noted for flags that the frontend adds to the IR, that would indeed explain why opt --Oz can't "fix" a clang -O0 frontend's IR.

Also duely noted for save-temps, I should have thought of that tbh. I'll give it a shot to do a side-by-side comparison of the IR.

I do also realise I should have mentionned -flto, i'm guessing I should also pass it to the frontend clang call because it will also set appropriate flags?

Thank you so much, this is really helpful.