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

> > We are currently doing this, however I think disabling such
> > optimizations is a much better solution.
> 
> An LLVM design goal is that backends should be able to outsmart
> instcombine when necessary, rather than having instcombine be able
> to disable parts of itself in order to avoid foiling the backends.
> Practicality sometimes steers elsewhere of course. Please explain
> why you think suppressing this particular optimization is better;
> it isn't obvious how it would look different in the end.
> 
Well, for one thing, our port has no native operation other than 8-bit
so it does not make sense to promote operations to higher precisions.
Eventually all those operations will be lowered and the resulting code
is most likely worse than if it was not promoted in the first place. So
I think it should be at the discretion of port to enable or disable such
optimizations as needed.

A

On Aug 4, 2009, at 12:19 AM, Alireza.Moshtaghi at microchip.com
wrote:
> Well, for one thing, our port has no native operation other than 8-bit
> so it does not make sense to promote operations to higher precisions.
> Eventually all those operations will be lowered and the resulting code
> is most likely worse than if it was not promoted in the first place.  
> 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.

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090804/67e126fc/attachment.bin>

> > 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.