[PATCH] D116735: [RISCV] Adjust RISCV data layout by using n32:64 in layout string

Zixuan Wu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 8 18:15:04 PST 2022


zixuan-wu added a comment.

In D116735#3225715 <https://reviews.llvm.org/D116735#3225715>, @craig.topper wrote:

> In D116735#3225286 <https://reviews.llvm.org/D116735#3225286>, @jrtc27 wrote:
>
>> That's trying to do `return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1;` for a range of x. Presumably the issue is MULW exists but not MULWHU and friends.
>
> So the `f` function gets inlined into this compare `f (i) != i / 3`. The i/3 gets optimized by SelectionDAG into `(unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1`. Before this patch, the automatic CSE in SelectionDAG merges this with the code from the inlined function. This makes a the comparison be statically always true so all the code gets optimized away.
>
> With this patch, LSR kicks in and rewrites some of the inlined code from f by removing the multiply with 0xAAAAAAAB in favor of a modified induction variable that increments by 0xAAAAAAAB on each iteration. Now there's nothing for the div by constant optimization to CSE with so the comparison doesn't become statically always true.
>
> I don't think this test is a blocker for this patch.

Does the patch improve performance absolutely in theory?
Could anybody else also test to see if the patch can improve performance because guys may have different environment or benchmarks?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116735/new/

https://reviews.llvm.org/D116735



More information about the llvm-commits mailing list