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

[Xinliang David Li]

ok thanks.

David

On Tue, Apr 14, 2015 at 10:33 AM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>
> 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/5b2a1218/attachment.html>