On 3/18/2021 9:08 AM, Jakub Jelinek 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.
In my mind it'd only be for the testsuite and would be documented as
such. I wouldn't want users twiddling it. We could do the same with
BRANCH_COST to simplify the insanity we have with target selectors in
various tests related to that. There's probably other cases where
testing-only params would be helpful.
Totally agree that improving the optimization & analysis to work with
both cases is also good and that it wouldn't be appropriate for gcc-11.
Jeff
