On Mon, Oct 15, 2012 at 6:39 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote:
>> On Fri, Oct 12, 2012 at 7:57 PM, Ulrich Weigand <uweig...@de.ibm.com> wrote: >> > I was wondering if the i386 port maintainers could have a look at this >> > pattern. Shouldn't we really have two patterns, one to *load* an unaligned >> > value and one to *store* and unaligned value, and not permit that memory >> > access to get reloaded? >> >> Please find attached a fairly mechanical patch that splits >> move_unaligned pattern into load_unaligned and store_unaligned >> patterns. We've had some problems with this pattern, and finally we >> found the reason to make unaligned moves more robust. >> >> I will wait for the confirmation that attached patch avoids the >> failure you are seeing with your reload patch. > > Yes, this patch does in fact fix the failure I was seeing with the > reload patch. (A full regression test shows a couple of extra fails: > FAIL: gcc.target/i386/avx256-unaligned-load-1.c scan-assembler sse_movups/1 > FAIL: gcc.target/i386/avx256-unaligned-load-3.c scan-assembler sse2_movupd/1 > FAIL: gcc.target/i386/avx256-unaligned-load-4.c scan-assembler avx_movups256/1 > FAIL: gcc.target/i386/avx256-unaligned-store-4.c scan-assembler > avx_movups256/2 > But I guess these tests simply need to be updated for the new pattern names.) Yes, the complete patch I am about to send to gcc-patches@ ML will include all testsuite adjustments. Uros.