As reported by Linus Torvalds:
https://lore.kernel.org/lkml/CAHk-=wg9p+oJtzC0582vke8whcWPNSC9eq0Z6kdnSqWMEpah7g@mail.gmail.com/
Details
- Reviewers
ributzka
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Hi @ributzka, do you have thoughts on how best to fix this issue demonstrated by this test case?
I have a patch that avoids hoisting to the same BB; not sure yet if there's perhaps a better approach.
llvm/test/Transforms/ConstantHoisting/X86/bad-cases.ll | ||
---|---|---|
130 | Why shouldn't this expensive constant be hoisted? The 68719476704 should be hoisted out of the BB and only the add should stay in %d. Why is 68719476704 materialized twice? |
llvm/test/Transforms/ConstantHoisting/X86/bad-cases.ll | ||
---|---|---|
130 |
I'm not even sure it's expensive on x86_64. Pretty sure it can fit in an immediate field for stores + comparisons.
Sure, that would have been acceptable, too.
That's what I'm curious about; this seems like a bug in ConstantHoist, right? |
Why shouldn't this expensive constant be hoisted? The 68719476704 should be hoisted out of the BB and only the add should stay in %d. Why is 68719476704 materialized twice?