Re: {PING] [PATCH] Sign extension elimination

["Leehod Baruch" <leehod dot baruch at weizmann dot ac dot il>]

> On Thu, Apr 20, 2006 at 12:11:27PM +0300, Leehod Baruch wrote:
>> If what you say here:
>> > We may be able to teach the x86-64 backend about SEE. If we can tell
>> SEE
>> that
>> > SI is always zero-extended to DI for a backend, SEE can do a much
>> > better job for x86-64.
>> is true, then the high part of reg 73 is a zero extension of the low
>> part
>> automatically without the need for an extension instruction or even an
>> extension that is embedded into the definition instruction, like the one
>> SEE is currently
>> producing:
>> >>             (set (reg:DI 73 [ t.42 ])
>> >>                 (zero_extend:DI (xor:SI (mem/s:SI (plus:DI (reg:DI 66
>> [
>> >> ivtmp.37 ])
>> And all the uses of reg:DI 73 may stay unchanged.
>>
>> Did I understand you correctly?
>
> Yes.
>
>>
>> On PPC the only implicit extensions are in instructions that
>> set a register with a constant value, e.g. setting a DI register with
>> the value 1 has an implicit extension.
>>
>
> It tries to eliminate SE by better placing SE.
This is not totally true.
The current SEE was designed to do three major things:
1. To exploit dual mode operations, i.e. to replace machine instructions
+ explicit extension with one machine instruction that can make
sign/zero extension "for free".
2. To eliminate redundant extension instructions, i.e. extensions that
are been generated automatically by the compiler right after the definition
but there is no use of the upper part. If the uses are in different bb
for example, the extensions won't be eliminated automatically.
3. To place the extensions instructions that we could not eliminate in
the optimal placement using partial redundancy elimination.

> But on x86-64, we have a different problem. No wonder it doesn't work
> there. We are investigating a different, simple approach based on the
> same infrastructure. I think it should work much better on x86-64.
> That means that we may have 2 different SEE passes, depending on the
> target.
Although the current SEE currently doesn't optimizes the testcase you
presented, don't you think it will contribute to x86-64 either?

> pseudo ext:
> set ((reg:DI 10) (pseudo_extend:DI (reg:SI 10)))
>
> simple move:
> set ((reg:DI 100) (reg:DI 10)))
>
> SEE should be enabled only for the backend with pseudo extensions.
>
What is this pseudo_extension? can you generate such RTL?

I think that, before you start implement a new SEE pass we should think
of generalizing the current one since the problems are not so different
and the current SEE infrastructure might be enough.


Leehod.