[PATCH] Fix a performance problem in gep(gep ...) merging

[Daniel Berlin]

On Tue, Apr 14, 2015 at 9:53 AM Xinliang David Li <xinliangli at gmail.com>
wrote:

> On Tue, Apr 14, 2015 at 8:46 AM, Daniel Berlin <dberlin at dberlin.org>
> wrote:
>
>> I think nick's question is more "is GEP merging really the only problem
>> this causes?"
>>
>
> Yes, blind merging (before the fix) can indeed cause more problems.
>
>> I know the answer is no, because PRE will go crazy and do this if you
>> make it powerful enough to see loop carried dependences and in GCC, it uses
>> an API to detect whether an insertion would be causing issues like this and
>> avoids doing it (which I believe a exactly Nick's suggestion - create a
>> utility others can use to avoid accidentally doing transforms like this in
>> the first place
>>
>
> IMO, this is a different issue that happens to overlap in scope a little
> with this one (when there is loop involved).  If LLVM's PRE has the problem
> of introducing loop carried dependency, we should file a bug (with a test
> case) to track it.
>

It does, but only for loads and their addressing calculations right now. It
assumes this is always worth eliminating a load for, even if it means
introducing loop carried arithmetic.

see test/Transforms/GVN/pre-load.ll test 9 and test 10.

If you unify the two PRE's (as i've done), it will happily do so for
everything, including induction variables, GEP's, etc.  This is the same
issue GCC"s PRE had. It's too smart, and ends up essentially peeling loop
iterations/etc.


> Does it make sense?   Wei can probably help with that too.
>
> I wouldn't worry about it, it will be a while before it becomes an issue
for PRE, and we can look at merging heuristics for this and that when
NewGVN + NewPRE gets submitted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150414/f3b43b2e/attachment.html>