[PATCH] Move away sign extensions that get in the way of addressing mode

[Quentin Colombet]

Hi chandlerc, grosbach, atrick,

Hi,

Here is a patch to move sign extensions away when matching an addressing mode in CodeGenPrepare.
Thanks for your review.

** Context **

It is customary to see this kind of unfriendly 64-bit code on 64-bit architecture:
int idx = a + 1;
myArray[idx];

Using a int type, contraints the computation on 32-bit. This prevents the computation to be folded into the load of myArray when the address space is 64-bit.
The related IR looks like:
%idx = add nsw i32 %a, 1
%sextidx = sext i32 %idx to i64
%gep = gep i8* %myArray, i64 %sextidx
load i8* %gep

The bottom line is sext gets in the way of the addressing mode.

** Proposed Patch **

The idea is to move the sign extensions away when they get in the way of addressing modes and it is legal to do so.
E.g., with the previous example this gives:
%sexta = sext i32 %a to i64
%idx = add nsw i64 %sexta, 1
%gep = gep i8* %myArray, i64 %idx
load i8* %gep

The legality of the transformation is based on the nsw/nuw flags. If none of these flags is present on the promotion is not legal.

The patch adds this transformation to CodeGenPrepare, more particularly, in the AddressingModeMatcher.
When the matcher sees a sign extension that gets in the way of an addressing mode, it tries to promote its operand. If the promotion is possible, it keeps matching the promoted instructions.
The logic for promoting the instructions is in the TypePromotionHelper class.

If the matching fails (not profitable, addressing mode not legal, etc.), the matcher will revert the related promotions. This logic is implemented in the TypePromotionTransaction class and the related helper classes: TypePromotionAction.

** Result **

I benchmarked this modification on the llvm-test-suite and SPECs for X86 with O3 and Os.
I did not see any measurable compile time impact with this new transformation other than noise.
Regarding the performances, some tests benefit a lot from this transformation (5-9%), most are unchanged. There was a few regressions that turned out to be noise.
Chandler saw similar unchanged performance impact on his side (thanks again for the measurements!).

Cheers,
-Quentin

http://llvm-reviews.chandlerc.com/D2621

Files:
  lib/Transforms/Scalar/CodeGenPrepare.cpp
  test/CodeGen/X86/codegen-prepare-addrmode-sext.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D2621.1.patch
Type: text/x-patch
Size: 50328 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140124/f3931fa9/attachment.bin>