[PATCH] D42536: [AggresiveInstCombine] Added support of select and ShuffleVector to TruncInstCombine expression pattern

Amjad Aboud via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Jan 28 07:38:58 PST 2018


aaboud added a comment.

In https://reviews.llvm.org/D42536#988422, @spatel wrote:

> That's too easy - instcombine gets that. I think you need at least one more intermediate binop to show a case that instcombine can't handle.


You are right, I forgot that instcombine algorithm can handle zext/sext with multi use in case they have same type as trunc instruction destination type.
Here is a better test suggestion:

  define void @multi_uses_add(i32 %X) {
    %A = zext i32 %X to i64
    %B = add i64 %A, 5
    %M1 = mul i64 %B, 66
    %M2 = mul i64 %B, %A
    %C = and i64 %M1, %M2
    %T = trunc i64 %C to i32
    call i32 @use32(i32 %T)
    ret void
  }



> We need to make sure aggressive-instcombine is showing its unique capability in each test. If you agree that the case with a repeated op is just an oversight for instcombine, lets:
> 
> 1. Move the existing tests over to instcombine
> 2. Fix instcombine

I agree that we should improve instcombine where ever it make sense, such as this case, but I am afraid that I have no time to do it myself.
So, if you would like to take this task, I will be happy to review the code.

> 3. Add more complex tests for aggressive-instcombine's current functionality

Do you agree to the above example? I can duplicate it to handle all other instructions.

> 4. Enhance aggressive-instcombine for more opcodes/patterns.

I will be adding more opcodes that trunc expression should support, and with each new opcode I will be adding more tests.
Also, I already added few tests that were driven from implementation bugs due to missing handle of constant expressions.
see https://reviews.llvm.org/D42622.


https://reviews.llvm.org/D42536





More information about the llvm-commits mailing list