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