[PATCH] D11051: Extend LICM to hoist loop invariant GEP out

[Quentin Colombet]

> On Jul 9, 2015, at 11:26 AM, Lawrence Hu <lawrence at codeaurora.org> wrote:
> 
> hulx2000 added a comment.
> 
> Hi, Quentin:
> 
> Thanks for your prompt response.
> 
> Just want to clarify, after the transformation, the new code would be:
> C = gep A, 1023
> D = gep C, B        // Note that B is still the second operand.

Right :).
The canonicalization would only be “push constant up in the chain of GEPs”.

> 
> Based on the testcase originated this, those GEPs were generated by Split GEP pass, that means originally there is only one GEP related to A, so overflow on the first or the second should not make too much difference, because they were all based on A originally , that's why I checked the type of A and C must be the same.
> 
> However whether the check is strict enough to make sure the transformation is legal, I am not 100% sure, definitely I'd like to hear more comments.
> 
> About doing it in inst combining,  I am not an expert of inst combining, my question is: is it possible for inst combining to hoist instruction outside loop?

It could but I would prefer it to not do the hoist, just the transformation. The idea was that the canonicalization would allow LICM to catch it without any special code, while inst combine would have canonicalized without thinking about loops… May be a bad idea though, I have given it much of a thought.

Cheers,
-Quentin

>   The important aspect of this transformation is to enable LICM to hoist a loop invariant computation outside loop, which is impossible before since the first GEP is loop variant, and we have to check if the first GEP is loop variant (or don't know), because this transformation is not needed otherwise -- If LICM can hoist the first GEP out, then it will hoist the second GEP out too.
> 
> More comments are welcome.
> 
> Regards
> 
> Lawrence Hu
> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D11051
> 
> 
>