This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Exploiting dual mode operation, implementation.


> No, I don't think so.  When I've examined this problem in the
> past, a typical failure case was:
>
>                (set (reg:si 100) (mem:si))
>                (set (reg:di 101) (sign_extend:di (reg:si 100)))
>                ...
>                (use (reg:si 100))
>                (use (reg:di 101))
>
> Combine will not optimize this, because reg100 has two uses.

The algorithm will handle this case, but there is something that 
I would like to understand. It seems that for a 64-bit 
architectures this is a very rare occurrence unless some 
optimization is done. For a reference to a 32-bit variable, we 
will have indeed

                 (set (reg:si 100) (mem:si))
                 (set (reg:di 101) (sign_extend:di (reg:si 100)))
                 ...

but afterward only reg101 (where the variable is loaded) will be 
used. reg100 will be used only as a temporary (register allocator 
may change this but it is done after our optimization). So not 
clear how you get the above pattern. On what architecture ? 

>> The sign-extensions are produced after the def regardless of the 
>> use, but on *many* cases the use uses only the low part. 

> Ok, give me some numbers for "many", and we'll have something to
> talk about.  At the moment all we have are wild assertions.

The profits gained by a similar optimization are promising - see
"Effective Sign Extension Elimination" by Kawahito M., Komatsu H., 
Nakatani T, PLDI 2002. These results (that triggered our work) 
show the potential of optimizing the sign extension instructions 
generated for 32-bit computations on 64-bit architectures. Of 
course, much depends on the instruction set of the underlying 
architecture.

Mircea


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]