On Thu, Mar 18, 2021 at 4:09 PM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > 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.
And/or relax the conditions under which we do the transform. Richard. > > Jakub >
