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
