> On 11/26/13 13:20, Jakub Jelinek wrote: > >Hi! > > > >As the testcase in the patch shows, if exact memcpy or memset count > >is unknown, but max_size is smaller than epilogue_size_needed, > >ix86_expand_set_or_movmem can ICE. > > > >The following patch fixes that, bootstrapped/regtested on x86_64-linux > >and i686-linux, ok for trunk? > > > >Though, the resulting code doesn't look very good, as everything is expanded > >as just epilogue of the copying/memset, I think the probabilities on the > >branches expect that all bits of the remaining size are 0 after the main > >loop (which isn't done in this case). > > > >2013-11-26 Jakub Jelinek <ja...@redhat.com> > > > > PR target/59229 > > * config/i386/i386.c (device_alg): Fix up formatting. > > (ix86_expand_set_or_movmem): Handle max_size < epilogue_size_needed > > similarly to count && count < epilogue_size_needed. Fix up > > comment typo. > > * builtins.c (determine_block_size): Fix comment typo. > > > > * gcc.c-torture/execute/pr59229.c: New test. > OK.
Thanks, I was looking into this testcase, too. It seems to me that perhaps we can get a bit better by doing the misaligned move prologue in these cases up to 128bytes when it starts to get too large. The code looks better than one porduced by the standard epilogue code and it works well on core. I wonder how much older chips care about the misalignment, but it is what move_by_pieces would do for constant size anyway, right? Honza
