[PATCH] D46760: [InstCombine] Enhance narrowUDivURem.
Sanjay Patel via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sun May 20 10:56:13 PDT 2018
spatel added a comment.
You want to narrow multi-use sequences of code because instcombine can't do that profitably using minimal peepholes:
Name: narrow expression
Pre: C1 u< 9945
%tmp2 = zext i32 C1 to i64
%lane_id = and i64 %tmp2, 31
%shr = lshr i64 %tmp2, 2
%tmp4 = shl nuw nsw i64 %shr, 5
%r = or i64 %lane_id, %tmp4
=>
%nlane_id = and i32 C1, 31
%nshr = lshr i32 C1, 2
%ntmp4 = shl i32 %nshr, 5
%ntmp5 = or i32 %nlane_id, %ntmp4
%r = zext i32 %ntmp5 to i64
The original motivation for -aggressive-instcombine (TruncInstCombine) was something almost like that - see https://reviews.llvm.org/D38313. Can you extend that? Note that the general problem isn't about udiv/urem, lshr, or any particular binop. It's about narrowing a sequence of arbitrary binops (and maybe even more than binops).
Re: instcombine - if some transform is increasing instruction count by not checking for uses, that's a bug. I think we established that conclusively in https://reviews.llvm.org/D44266.
The problem with trying to do this transform in instcombine by checking the users is that if it's ok to check the users for this 1 transform, then why don't we do that for *every* transform? The compile-time cost of that change would be substantial, and we're trying to limit the cost of instcombine. See recent llvm-dev discussions for more details.
Repository:
rL LLVM
https://reviews.llvm.org/D46760
More information about the llvm-commits
mailing list