llvm dev - Aug 2009 - [LLVMdev] disabling combining load/stores in optimizer.

> > So I think it should be at the discretion of port to enable or
disable
> > such optimizations as needed.
> 
> While that it a valid approach in general, it is completely at odds
> with the approach that the LLVM codebase has taken.  The general LLVM
> philosophy is that all optimizations should be as aggressive as
> possible at whatever they do, and it is then the responsibility of the
> target to lower what the optimizers produce into something legal for
> that machine.
> 
> Contravention of that design philosophy in a major portion of the
> optimization suite is unlikely at best, to be honest.
> 
I can see the benefits of this approach at a macro-level, however at
micro-level the impact is visible especially in embedded targets with
limited memory and register resources (such as pic16)
We see the impact not only wrto code quality but also compile time (to
recover the damage that the optimizer has done). The other problem is
that our port never seem to be stable because as such generic
optimizations get added, something new will break in our port and as
more and more higher end targets are being ported to llvm I expect more
and more optimizations be added that are at odds with our port.
That is why we are asking for a way to at least have some control on
such optimizations.

A.

On Aug 4, 2009, at 9:51 AM, Alireza.Moshtaghi at microchip.com wrote:
>
>>> So I think it should be at the discretion of port to enable or
> disable
>>> such optimizations as needed.
>>
>> While that it a valid approach in general, it is completely at odds
>> with the approach that the LLVM codebase has taken.  The general LLVM
>> philosophy is that all optimizations should be as aggressive as
>> possible at whatever they do, and it is then the responsibility of  
>> the
>> target to lower what the optimizers produce into something legal for
>> that machine.
>>
>> Contravention of that design philosophy in a major portion of the
>> optimization suite is unlikely at best, to be honest.
>>
>
> I can see the benefits of this approach at a macro-level, however at
> micro-level the impact is visible especially in embedded targets with
> limited memory and register resources (such as pic16)
Is this actually causing a performance problem in practice?  If so,  
please show the generated and desired code for a tiny testcase.   
Instead of talking theory, please give an example.

-Chris

On Tuesday 04 August 2009 12:06, Chris Lattner wrote:
> > I can see the benefits of this approach at a macro-level, however at
> > micro-level the impact is visible especially in embedded targets with
> > limited memory and register resources (such as pic16)
>
> Is this actually causing a performance problem in practice?  If so,
> please show the generated and desired code for a tiny testcase.
> Instead of talking theory, please give an example.
Obviously I don't have a PIC16 example, but we've seen many cases in our
own optimizer where we've had to throttle things, especially for register
pressure.  Sometimes the backend really can't recover because there
isn't
enough information to do so.

Generally I abhor throttles.  But sometimes they are necessary because the
earlier passes have the right information to make the decisions.

                             -Dave

On Tuesday 04 August 2009 11:51, Alireza.Moshtaghi at microchip.com wrote:
> recover the damage that the optimizer has done). The other problem is
> that our port never seem to be stable because as such generic
> optimizations get added, something new will break in our port and as
> more and more higher end targets are being ported to llvm I expect more
> and more optimizations be added that are at odds with our port.
Well, this part is on you.  AFAIK, the only PIC16 tests in the LLVM testsuite
were generated by others.  It's up to you to put tests in the testbase that
people can run.  We can't anticipate the affects of choices on your port if
your port isn't part of the regular testing regime.

                               -Dave

> 
> Is this actually causing a performance problem in practice?  If so,
> please show the generated and desired code for a tiny testcase.
Not anymore; the performance problem has been addressed. Though, there
are other examples of this sort which do not really relate to the
subject of this thread so I would like to discuss them at a different
time. 

Thanks for the link to the other thread:
"Adding legal integer sizes to TargetData"

Cheers,
Ali.