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 .

<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!


Segher

Reply via email to