llvm dev - Feb 2013 - [LLVMdev] [Polly] Aliasing problems escalation (WAS: Re: [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?)

Hi Dmitry,

On 15/01/13 22:22, Dmitry Mikushin wrote:
> Hi Duncan,
>
> You mean - what happens if DragonEgg is invoked with GCC optimization? I
tried
> -O3 and -fplugin-arg-dragonegg-llvm-ir-optimize=1, but nothing changed.
no, I meant if you run gcc with optimization and don't use dragonegg at all.
If I understand right, your problem is that the LLVM optimizers don't remove
some loads, and this blocks polly.  If the GCC optimizers are able to remove
the loads, then that means that the gcc optimizers have access to some info
that the LLVM optimizers don't have (because removing the loads is invalid
given the information currently in the IR).  We would then have to just have
to teach dragonegg to extract that information and pass it on to the LLVM
optimizers.

Ciao, Duncan.
>
> - D.
>
> 2013/1/8 Duncan Sands <baldrick at free.fr <mailto:baldrick at
free.fr>>
>
>     On 04/01/13 15:58, Duncan Sands wrote:
>
>         PS: Another possibility is to do link-time optimization, since at
that
>         point the
>         optimizers are capable of finding out if that global is used
anywhere
>         else or
>         not.
>
>
>     By the way, do the GCC optimizers get this, i.e. remove the loads?
>
>     Ciao, Duncan.
>
>

Hi Duncan,

Got it. So, it looks like in [case] it is really sufficient to have -O1 for
GCC to remove loads (not really remove, but rather pull outside of loops,
which is sufficient).

And in this case - GCC -O1 does not help.

Still, is the [case] sufficient for you to track the missing GCC's info and
make it accessible to LLVM? Meanwhile, I think we will use GCC -O1,
however, I guess, it would likely introduce other issues in turn. Oh.

[case] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059313.html

Thanks,
- D.

2013/1/16 Duncan Sands <baldrick at free.fr>
> Hi Dmitry,
>
>
> On 15/01/13 22:22, Dmitry Mikushin wrote:
>
>> Hi Duncan,
>>
>> You mean - what happens if DragonEgg is invoked with GCC optimization?
I
>> tried
>> -O3 and -fplugin-arg-dragonegg-llvm-**ir-optimize=1, but nothing
changed.
>>
>
> no, I meant if you run gcc with optimization and don't use dragonegg at
> all.
> If I understand right, your problem is that the LLVM optimizers don't
> remove
> some loads, and this blocks polly.  If the GCC optimizers are able to
> remove
> the loads, then that means that the gcc optimizers have access to some info
> that the LLVM optimizers don't have (because removing the loads is
invalid
> given the information currently in the IR).  We would then have to just
> have
> to teach dragonegg to extract that information and pass it on to the LLVM
> optimizers.
>
> Ciao, Duncan.
>
>
>> - D.
>>
>> 2013/1/8 Duncan Sands <baldrick at free.fr <mailto:baldrick at
free.fr>>
>>
>>
>>     On 04/01/13 15:58, Duncan Sands wrote:
>>
>>         PS: Another possibility is to do link-time optimization, since
at
>> that
>>         point the
>>         optimizers are capable of finding out if that global is used
>> anywhere
>>         else or
>>         not.
>>
>>
>>     By the way, do the GCC optimizers get this, i.e. remove the loads?
>>
>>     Ciao, Duncan.
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130210/e33b0d69/attachment.html>

Update: in the case discussed in *this* thread, GCC optimization also
helps: with -O2 GCC pulls out dimensions loads from loops. Polly still has
a problem due to bitcast, but this is another issue.

- D.

2013/2/10 Dmitry Mikushin <dmitry at kernelgen.org>
> Hi Duncan,
>
> Got it. So, it looks like in [case] it is really sufficient to have -O1
> for GCC to remove loads (not really remove, but rather pull outside of
> loops, which is sufficient).
>
> And in this case - GCC -O1 does not help.
>
> Still, is the [case] sufficient for you to track the missing GCC's info
> and make it accessible to LLVM? Meanwhile, I think we will use GCC -O1,
> however, I guess, it would likely introduce other issues in turn. Oh.
>
> [case]
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/059313.html
>
> Thanks,
> - D.
>
> 2013/1/16 Duncan Sands <baldrick at free.fr>
>
>> Hi Dmitry,
>>
>>
>> On 15/01/13 22:22, Dmitry Mikushin wrote:
>>
>>> Hi Duncan,
>>>
>>> You mean - what happens if DragonEgg is invoked with GCC
optimization? I
>>> tried
>>> -O3 and -fplugin-arg-dragonegg-llvm-**ir-optimize=1, but nothing
>>> changed.
>>>
>>
>> no, I meant if you run gcc with optimization and don't use
dragonegg at
>> all.
>> If I understand right, your problem is that the LLVM optimizers
don't
>> remove
>> some loads, and this blocks polly.  If the GCC optimizers are able to
>> remove
>> the loads, then that means that the gcc optimizers have access to some
>> info
>> that the LLVM optimizers don't have (because removing the loads is
invalid
>> given the information currently in the IR).  We would then have to just
>> have
>> to teach dragonegg to extract that information and pass it on to the
LLVM
>> optimizers.
>>
>> Ciao, Duncan.
>>
>>
>>> - D.
>>>
>>> 2013/1/8 Duncan Sands <baldrick at free.fr <mailto:baldrick
at free.fr>>
>>>
>>>
>>>     On 04/01/13 15:58, Duncan Sands wrote:
>>>
>>>         PS: Another possibility is to do link-time optimization,
since
>>> at that
>>>         point the
>>>         optimizers are capable of finding out if that global is
used
>>> anywhere
>>>         else or
>>>         not.
>>>
>>>
>>>     By the way, do the GCC optimizers get this, i.e. remove the
loads?
>>>
>>>     Ciao, Duncan.
>>>
>>>
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130210/23a634af/attachment.html>