Alireza.Moshtaghi at microchip.com
2009-Mar-19 17:38 UTC
[LLVMdev] Proposal to disable some of DAG combine optimizations
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
someguy
2009-Mar-19 18:23 UTC
[LLVMdev] Proposal to disable some of DAG combine optimizations
I'd find this useful too. On Thu, Mar 19, 2009 at 7:38 PM, <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 >
Dan Gohman
2009-Mar-20 00:39 UTC
[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
Alireza.Moshtaghi at microchip.com
2009-Mar-23 04:39 UTC
[LLVMdev] Proposal to disable some of DAG combine optimizations
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090322/e3f05fca/attachment.html>
Maybe Matching Threads
- [LLVMdev] Proposal to disable some of DAG combine optimizations
- [LLVMdev] Proposal to disable some of DAG combine optimizations
- [LLVMdev] Proposal to disable some of DAG combine optimizations
- [LLVMdev] Proposal to disable some of DAG combine optimizations
- how to skip a specific value when using apply() function to a matrix?