On Thu, Mar 18, 2021 at 08:58:20AM -0600, Jeff Law via Gcc-patches wrote:
>
> On 3/18/2021 8:37 AM, Jakub Jelinek via Gcc-patches wrote:
> > Hi!
> >
> > Similar issue as in strlenopt-73.c, various spots in this test rely
> > on MOVE_MAX >= 8, this time it uses a target selector to pick up a couple
> > of targets, and all of them but powerpc 32-bit satisfy it, but powerpc
> > 32-bit have MOVE_MAX just 4.
> >
> > Tested on x86_64-linux and powerpc64-linux -m32/-m64, ok for trunk?
> >
> > 2021-03-18 Jakub Jelinek <ja...@redhat.com>
> >
> > PR testsuite/99636
> > * gcc.dg/strlenopt-80.c: For powerpc*-*-*, only enable for lp64.
>
> OK. But it'd sure be nice to be able to do something like force a value of
> MOVE_MAX using a --param to make this kind of hack unnecessary.
I fear such a param would be quite dangerous, dunno what would happen if
somebody chose a length that can't be backed up by some integral or SIMD
type. Maybe for the gimple-fold.c case
tree type = lang_hooks.types.type_for_size (ilen * 8, 1);
if (type
&& is_a <scalar_int_mode> (TYPE_MODE (type), &mode)
&& GET_MODE_SIZE (mode) * BITS_PER_UNIT == ilen * 8
would fail (so we couldn't handle that way the 16 byte case anyway on all
targets), but there are other parts of the compiler that use MOVE_MAX.
I think maybe better would be to instead improve the optimization so that
it would work even with the non-lowered memcpy calls. But that would be
a GCC12 thing probably.
Jakub
