[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 at gcc dot gnu dot org>]

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.