Details
- Reviewers
spatel arsenm foad nikic lebedev.ri
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
60,060 ms | x64 debian > libFuzzer.libFuzzer::minimize_crash.test |
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
846 | Should that be "Only the K trailing bits..." or "The 'width - K' leading bits must be zero."? |
llvm/lib/Transforms/InstCombine/InstCombineShifts.cpp | ||
---|---|---|
873–875 | Should be '>' instead of '!=' surely? It would be fine if these values happen to have more leading zeros than required. |
llvm/test/Transforms/InstCombine/shift-add.ll | ||
---|---|---|
511 | Demanded bits should always zap cases like this. So we'd be back to creating 2 extra instructions vs. the original sequence. That doesn't seem like a good trade-off in IR. | |
519 | wrong hex value comment - 0xFFFF |
llvm/test/Transforms/InstCombine/shift-add.ll | ||
---|---|---|
519 | There is a rarely used syntax to use hex constants in the IR but I never remember what it is |
(marking as reviewed)
llvm/test/Transforms/InstCombine/shift-add.ll | ||
---|---|---|
511 | Presumably we can simply avoid that unprofitable case, |
Comments
llvm/test/Transforms/InstCombine/shift-add.ll | ||
---|---|---|
511 | It does removes it, not sure why it didn't there. Maybe I forgot to rebase? |
llvm/test/Transforms/InstCombine/shift-add.ll | ||
---|---|---|
511 | Yes - that seems like it would be ok; just restrict the pre-condition with ShAmt to equality (it was like that in an earlier draft?). | |
511 | My comment might not have been clear:
|
Would you mind pre-commit the new/update tests? The test diff is a bit hard to follow right now.
Do I understand right that we will replace two ands, one add and a lshr with two truncs, a uaddo and a zext? It's not super obvious that this is beneficial, but I guess the hope is that this will interact positively with other transforms (e.g. by pushing the trunc through operations and eliminating it entirely, or something)?
We don't use uaddo but rather (a + b) < b. The intention is indeed to:
- Positively interact with other transforms
- Get a better canonical form that's more easily recognizable by backends (end goal being to solve https://github.com/RadeonOpenCompute/ROCm/issues/488)
Initially we were using uaddo but it was decided to not have an intrinsic as a canonical form - I don't remember exactly why.
Should that be "Only the K trailing bits..." or "The 'width - K' leading bits must be zero."?