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

[Dmitry Mikushin]

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>