This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Exploiting dual mode operation, implementation.
- From: Mircea Namolaru <NAMOLARU at il dot ibm dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Leehod Baruch <LEEHOD at il dot ibm dot com>, Leehod Baruch <sleehodb at t2 dot technion dot ac dot il>, stevenb at suse dot de
- Date: Thu, 4 Aug 2005 14:19:51 +0200
- Subject: 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