[LLVMdev] Proposal to disable some of DAG combine optimizations

[Evan Cheng]

The code sequence:
> store %tmp1, var
> > tmp4 = add %tmp3 , %tmp1
>

can happen even if you eliminate the specific dag combine in question.  
The real solution lies elsewhere. To me, this seems more like a  
register allocation problem.

Evan

On Mar 22, 2009, at 9:39 PM, Alireza.Moshtaghi at microchip.com wrote:

> I can't think of any workaround? this optimization eliminates so  
> much information that if we want to retrieve back, it will take a  
> lot of processing and may not necessarily be able to retrieve the  
> lost information for all cases.
> Besides, why does the generic part of llvm have to force an  
> optimization that is counter productive to some targets?
> If there are other phases that do the same optimization, I think we  
> should also be able to disable them in those phases as well.
>
> A.
>
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu on behalf of Dan Gohman
> Sent: Thu 3/19/2009 5:39 PM
> To: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Proposal to disable some of DAG combine  
> optimizations
>
> Disabling this optimization in the DAG combiner isn't going to
> eliminate the problem; instcombine, GVN, and maybe even others also
> happen to perform this optimization. You may find it more effective
> to look for ways for codegen to recover in these kinds of situations.
>
> Dan
>
> On Mar 19, 2009, at 10:38 AM, Alireza.Moshtaghi at microchip.com wrote:
>
> > Some of the optimizations that the first DAG combine performs is
> > counter
> > productive for our 8-bit target. For example in:
> >
> > // I dropped the types because they are irrelevant.
> > // Excuse me for changing the syntax...
> > store %tmp1, %var
> > %tmp2 = load %var
> > %tmp4 = add %tmp3, %tmp2
> >
> > Since load is the only user of var and since var has just be stored
> > to,
> > it assumes that %tmp1 is alive and it goes ahead and removes the  
> load
> > and does:
> >
> > store %tmp1, var
> > tmp4 = add %tmp3 , %tmp1
> >
> > This is great for architectures that have more than one registers
> > because it is likely that value of %tmp1 is already in a physical
> > register, hence saving an instruction. However for our 8-bit
> > architecture with only one register, this kind of assumptions will
> > just
> > result in extra overhead because "add" operates only on memory, so  
> we
> > have to generate more instructions to store tmp1 to memory and then
> > use
> > that memory location for "add". But without the optimizations, we
> > could
> > just use var and everything would work out just fine.
> >
> > So I propose to add a bit mask and a method to TargetLowering  
> class so
> > targets can individually select some of the optimizations to be  
> turned
> > off.
> >
> > Thoughts?
> >
> > Alireza Moshtaghi
> > Senior Software Engineer
> > Development Systems, Microchip Technology
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> 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/20090323/96174ed0/attachment.html>