llvm dev - Apr 2009 - [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

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

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