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.