[Bug target/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Dec 8 00:13:00 GMT 2010
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #63 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-08 00:12:52 UTC ---
Created attachment 22678
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22678
gcc46-pr41082.patch
Totally untested proof of concept patch.
The disadvantage is that as the MEM mode is not altivec-ish, it isn't forced
into reg+reg addressing early.
On the other side, when rs6000_expand_vector_extract always creates a new stack
local (shouldn't it try to share just one such slot for each mode in each
function btw?), is there any reason why a normal stvx insn can't be used
instead of these stve*x insns? Is it a performance issue? The difference
between stvx and stve*x I understand is just that stve*x doesn't clobber in the
memory
other bytes, while stvx stores everything in the 16 byte slot. But we don't
care about those other bytes anyway, so if it is not a performance issue, IMHO
we should just get rid of UNSPEC_STVE stuff and store the whole vector, then
just read the bytes we want.
More information about the Gcc-bugs
mailing list