Three old entries from PROBLEMS

[Gerald Pfeifer]

At http://gcc.gnu.org/projects/#the_old_problems_file we have a short
list coming from the GCC 2 PROBLEMS file.  Instead of carrying this
around forever, I am wondering whether we could quickly review these
and either remove (as not applicable any longer) or move to Bugzilla?

  <li value="110">Possible special combination pattern: If the two
  operands to a comparison die there and both come from insns that are
  identical except for replacing one operand with the other, throw away
  those insns.  Ok if insns being discarded are known 1 to 1.  An andl
  #1 after a seq is 1 to 1, but how should compiler know that?</li>
 
  <li value="117">Any number of slow zero-extensions in one loop, that
  have their clr insns moved out of the loop, can share one register if
  their original life spans are disjoint.  But it may be hard to be sure
  of this since the life span data that regscan produces may be hard to
  interpret validly or may be incorrect after cse.</li>

  <li value="118">In cse, when a bfext insn refers to a register, if the
  field corresponds to a halfword or a byte and the register is
  equivalent to a memory location, it would be possible to detect this
  and replace it with a simple memory reference.</li>

I'll be glad to take care of it, provided guidance from subject matter
experts what to do about these three.

Gerald

[Paolo Bonzini-6]

>    <li value="110">Possible special combination pattern: If the two
>    operands to a comparison die there and both come from insns that are
>    identical except for replacing one operand with the other, throw away
>    those insns.  Ok if insns being discarded are known 1 to 1.  An andl
>    #1 after a seq is 1 to 1, but how should compiler know that?</li>

That would be:

add r4, r1, r2  (or sub by inverting the compare operands, or xor
                  if used in an equality/inequality comparison)
add r5, r1, r3
cmp r4, r5      -> cmp r2, r3

We don't do this, but it doesn't seem hard to do on the tree level (e.g.
in reassoc) or in combine for -fstrict-overflow.  Nice trick, worth a
Bugzilla entry IMO.

I don't understand the last sentence.

>    <li value="117">Any number of slow zero-extensions in one loop, that
>    have their clr insns moved out of the loop, can share one register if
>    their original life spans are disjoint.  But it may be hard to be sure
>    of this since the life span data that regscan produces may be hard to
>    interpret validly or may be incorrect after cse.</li>

That would be:

clr r7
clr r8
...
move strict-low-part(r7), r0
...
move strict-low-part(r8), r1 --> could reuse r7

This is not implemented but IMHO obsolete, most of the targets will just
use an AND to implement zero extension.

>    <li value="118">In cse, when a bfext insn refers to a register, if the
>    field corresponds to a halfword or a byte and the register is
>    equivalent to a memory location, it would be possible to detect this
>    and replace it with a simple memory reference.</li>

I think we do this in combine now.

Paolo

[Joern Rennecke-4]

Quoting Paolo Bonzini <bonzini@...>:

>
>>   <li value="110">Possible special combination pattern: If the two
>>   operands to a comparison die there and both come from insns that are
>>   identical except for replacing one operand with the other, throw away
>>   those insns.  Ok if insns being discarded are known 1 to 1.  An andl
>>   #1 after a seq is 1 to 1, but how should compiler know that?</li>
>
> That would be:
>
> add r4, r1, r2  (or sub by inverting the compare operands, or xor
>                  if used in an equality/inequality comparison)
> add r5, r1, r3
> cmp r4, r5      -> cmp r2, r3
>
> We don't do this, but it doesn't seem hard to do on the tree level
> (e.g. in reassoc) or in combine for -fstrict-overflow.  Nice trick,
> worth a Bugzilla entry IMO.

This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or you'd need
a target hook to classify CCmode modes to check if they are used only
for equality comparisons and can have their inputs altered.

> I don't understand the last sentence.
>
>>   <li value="117">Any number of slow zero-extensions in one loop, that
>>   have their clr insns moved out of the loop, can share one register if
>>   their original life spans are disjoint.  But it may be hard to be sure
>>   of this since the life span data that regscan produces may be hard to
>>   interpret validly or may be incorrect after cse.</li>
>
> That would be:
>
> clr r7
> clr r8
> ...
> move strict-low-part(r7), r0
> ...
> move strict-low-part(r8), r1 --> could reuse r7
>
> This is not implemented but IMHO obsolete, most of the targets will
> just use an AND to implement zero extension.

If the target can actually write to partial registers and refer to the
entire register without undue delay, you won't need and zero_extend or
AND operation at all.  So this is obsolete only to the extent that such
targets have become fewer / more arcane.
FWIW the ARC mxp had that feature, but it doesn't look like that port
will get into gcc mainline.

[Joern Rennecke-4]

Quoting Joern Rennecke <amylaar@...>:

> Quoting Paolo Bonzini <bonzini@...>:
...

>> That would be:
>>
>> clr r7
>> clr r8
>> ...
>> move strict-low-part(r7), r0
>> ...
>> move strict-low-part(r8), r1 --> could reuse r7
>>
>> This is not implemented but IMHO obsolete, most of the targets will
>> just use an AND to implement zero extension.
>
> If the target can actually write to partial registers and refer to the
> entire register without undue delay, you won't need and zero_extend or
> AND operation at all.  So this is obsolete only to the extent that such
> targets have become fewer / more arcane.
> FWIW the ARC mxp had that feature, but it doesn't look like that port
> will get into gcc mainline.

P.S.: more common in contemporary targets is the availability of vector
operations.  In order to use these to save zero extensions, instead of  
the result register you need the inputs to be prepared with a zero  
highpart.
E.g. to do a loop with an unsigned short biv, you zero-extend the initial
biv value and the loop increment value, then use a vector add for the biv
increment operation.

[Paolo Bonzini-6]

On 11/02/2009 08:49 AM, Joern Rennecke wrote:
>
> This would only be valid if the comparison is in an equality context
> (or for special input operand ranges).
> So (unless the target is CC0) you'd either have to use dataflow analysis
> to look at all the contexts the comparison result is used in, or you'd need
> a target hook to classify CCmode modes to check if they are used only
> for equality comparisons and can have their inputs altered.

Yes, that's why I suggested doing it on the tree level instead.

>> This is not implemented but IMHO obsolete, most of the targets will
>> just use an AND to implement zero extension.
>
> If the target can actually write to partial registers and refer to the
> entire register without undue delay, you won't need and zero_extend or
> AND operation at all.  So this is obsolete only to the extent that such
> targets have become fewer / more arcane.

Yes, that's what I meant.  The implementation effort is much less justified.

Paolo

[Richard Henderson-2]

On 11/01/2009 04:03 PM, Paolo Bonzini wrote:
>
>> An andl
>> #1 after a seq is 1 to 1, but how should compiler know that?</li>
>
> I don't understand the last sentence.

I think it's talking about something like

int f(int x, int y)
{
   int r;
   r = x == y;
   r &= 1;
   return r;
}

        cmpl %esi, %edi
        sete %al
        andl $1, %eax

Not the most ideal way to zero-extend the return value, from a partial
register stall point of view.  Note that with char values, we do
eliminate the AND operation, so this is not (any longer) about some pass
not understanding STORE_FLAG_VALUE.


r~

[Richard Henderson-2]

On 11/02/2009 09:37 AM, Richard Henderson wrote:
> Note that with char values, we do
> eliminate the AND operation, so this is not (any longer) about some pass
> not understanding STORE_FLAG_VALUE.

... or maybe it is.  We probably should have eliminated the AND at the
gimple level.


r~