Greg McGary
2009-Apr-21 23:02 UTC
[LLVMdev] Unnecessary moves after sign-extension in 2-address target
Dan Gohman wrote:> On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: > >> Because sextb_r and sextw_r have destination tied to source operands, >> TwoAddressInstructionPass thinks it needs a copy. However, since the >> sext kills its source, the copy is unnecessary. Why does this happen? >> Is TwoAddressInstructionPass relying on a later pass to notice this >> and >> transform it again? >> > > Yes, the later pass is the coalescer. It would be worthwhile to > understand why it is not coalescing the copies. >I discovered a curious phenomenon: The copies are necessary because TwoAddressInstructionPass commutes the second add. When I suppress the commute, the movs disappear and the code became optimal. It seems the two-address commuter is either buggy or inherently short-sighted/simple-minded and paints itself into a corner. How do you recommend I approach this problem? G
Evan Cheng
2009-Apr-22 05:03 UTC
[LLVMdev] Unnecessary moves after sign-extension in 2-address target
On Apr 21, 2009, at 4:02 PM, Greg McGary wrote:> Dan Gohman wrote: >> On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: >> >>> Because sextb_r and sextw_r have destination tied to source >>> operands, >>> TwoAddressInstructionPass thinks it needs a copy. However, since >>> the >>> sext kills its source, the copy is unnecessary. Why does this >>> happen? >>> Is TwoAddressInstructionPass relying on a later pass to notice this >>> and >>> transform it again? >>> >> >> Yes, the later pass is the coalescer. It would be worthwhile to >> understand why it is not coalescing the copies. >> > > I discovered a curious phenomenon: > > The copies are necessary because TwoAddressInstructionPass commutes > the second add. When I suppress the commute, the movs disappear and > the code became optimal. It seems the two-address commuter is > either buggy > or inherently short-sighted/simple-minded and paints itself into a > corner. > > How do you recommend I approach this problem?You can try to identify the problem in 2addr pass and try to provide us with a patch. Or file a bugzilla with a reproducible test case. Evan> > G > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Greg McGary
2009-Apr-22 15:58 UTC
[LLVMdev] Unnecessary moves after sign-extension in 2-address target
Evan Cheng wrote:> >> The copies are necessary because TwoAddressInstructionPass commutes >> the second add. When I suppress the commute, the movs disappear and >> the code became optimal. It seems the two-address commuter is >> either buggy >> or inherently short-sighted/simple-minded and paints itself into a >> corner. >> >> How do you recommend I approach this problem? >> > > You can try to identify the problem in 2addr pass and try to provide > us with a patch. Or file a bugzilla with a reproducible test case. >OK. I was really fishing for strategic direction: e.g., caveats with the heuristics/algorithms we use now. Of course, if such existed, I expect it would be present as comments, so it was probably too much to hope for... I'll see if I can get the x86 target to trip on this bug. My new port won't be suitable for a bug report, since it's an odd-ball proprietary CPU that will probably never be distributed outside the company. G
Greg McGary
2009-Apr-24 00:05 UTC
[LLVMdev] Unnecessary moves after sign-extension in 2-address target
Greg McGary wrote:> I discovered a curious phenomenon: > > The copies are necessary because TwoAddressInstructionPass commutes > the second add. When I suppress the commute, the movs disappear and > the code became optimal. It seems the two-address commuter is either buggy > or inherently short-sighted/simple-minded and paints itself into a corner. >I have some understanding of what goes no here. One of the cases where TwoAddressInstructionPass commutes is when it can shorten the live range of a src/dest operand. Maybe this is good for x86, but is bad for my CPU which has 32 GPRs, so doesn't need to sacrifice in order to reduce register pressure. Actually, in my small tests I haven't seen x86 suffer from removing this class of commutations. I'll see how things go for x86 on some larger things in test-suite before I determine whether my change works for x86. If it loses for x86, it still wins for my port, so I can make this commutation case depend on a parameter of the target. G
Apparently Analagous Threads
- [LLVMdev] Unnecessary moves after sign-extension in 2-address target
- [LLVMdev] Unnecessary moves after sign-extension in 2-address target
- [LLVMdev] Unnecessary moves after sign-extension in 2-address target
- [LLVMdev] Unnecessary moves after sign-extension in 2-address target
- Change Bit Value To Text When Viewed