Hi Segher!
on 2022/9/28 22:55, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
>> As PR106516 shows, we can get unexpected gimple outputs for
>> function thud on some target which supports modulus operation
>> for vector int. This patch introduces one effective target
>> vect_int_mod for it, then adjusts the test case with it.
>
>> +# Return 1 if the target supports vector int modulus, 0 otherwise.
>> +
>> +proc check_effective_target_vect_int_mod { } {
>> + return [check_cached_effective_target_indexed vect_int_mod {
>> + expr { [istarget powerpc*-*-*]
>> + && [check_effective_target_power10_ok] }}]
>> +}
>
> power10_ok does not mean the vmod[su][wdq] instructions will be
> generated. You need to test if we have -mcpu=power10 or such, so,
> check_effective_target_has_arch_pwr10 .
Indeed, the context is different from those cases in gcc.target/powerpc
which have -mdejagnu-cpu=power10 normally. Thanks for catching and
the correction!
>
> <X>_ok tests if it is okay to enable <X>. <X>_hw tests if the hardware
> can do <X>. has_arch_<X> tests if the compiler is asked to generate
> code for <X> (which is reflected in the _ARCH_* preprocessor symbols,
> hence the name).
>
> Okay for trunk with the correct check_effective_target_* . Thanks!
>
Thanks, re-tested as before, committed in r13-2983.
BR,
Kewen
