[PATCH] testsuite: Fix up strlenopt-80.c on powerpc [PR99636]

[Jeff Law]

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  <jakub@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