David Edelsohn wrote:
The zero_extend was added for a specific optimization reason. It
was suppose to represent to the compiler tha the load implicitly was
performing a zero_extend, not forcing the compiler to emit a
zero_extend.
I would like is some explanation why the original motivation for
wrapping
the move in zero_extend a few years ago is superceded or no longer
applicable.
I found that patch, and the test cas I think it is dealing with is,
struct x { unsigned char c; };
unsigned char foo(struct x* x, unsigned char q) {
return x->c + (unsigned int)(255 - x->c)*q;
}
(this did not appear to be committed with the patch, so I cannot be
sure).
Anyhow, before and after my patch I get the same code with -m32 and
-m64,
namely
-02 -m32
foo:
lbz 3,0(3)
subfic 0,3,255
mullw 0,0,4
add 3,3,0
rlwinm 3,3,0,0xff
blr
-O2 -m64
.foo:
lbz 3,0(3)
subfic 0,3,255
mullw 0,0,4
add 3,3,0
rldicl 3,3,0,56
blr
I too recently copied the ARM zero_extend idiom to a new design, but
later found it broke in exactly the way ppc is breaking. AFAICT, as
long as there's a pattern to match
(set (reg) (zero_extend (mem (reg))))
combine will combine as needed.
What is the purpose of LOAD_EXTEND_OP if one has to explicitly wrap
loads with ZERO_EXTENDs?
Was the SPEC run with 32-bit PowerPC or 64-bit PowerPC?
64 bit
nathan
--
Nathan Sidwell :: http://www.codesourcery.com ::
CodeSourcery LLC
nathan@codesourcery.com ::
http://www.planetfall.pwp.blueyonder.co.uk