on 2024/2/21 09:37, Peter Bergner wrote:
> On 2/20/24 3:27 AM, Kewen.Lin wrote:
>> on 2024/2/20 02:45, Segher Boessenkool wrote:
>>> On Tue, Jan 16, 2024 at 10:50:01AM +0800, Kewen.Lin wrote:
>>>> it consists of some aspects:
>>>> - effective target powerpc_p{8,9}vector_ok are removed
>>>> and replaced with powerpc_vsx_ok.
>>>
>>> So all such testcases already arrange to have p8 or p9 some other way?
>
> Shouldn't that be replaced with powerpc_vsx instead of powerpc_vsx_ok?
> That way we know VSX code gen is enabled for the options being used,
> even those in RUNTESTFLAGS.
>
> I thought we agreed that powerpc_vsx_ok was almost always useless and
> we always want to use powerpc_vsx. ...or did I miss that we removed
> the old powerpc_vsx_ok and renamed powerpc_vsx to powerpc_vsx_ok?
Yes, I think we all agreed that powerpc_vsx matches more with what we
expect, but I'm hesitating to make such change at this stage because:
1. if testing on an env without vsx support, the test results on these
affected test cases may change a lot, as many test cases would
become unsupported (they pass before with explicit -mvsx before).
2. teach current powerpc_vsx to make use of current_compiler_flags
just like some existing practices on has_arch_* may help mitigate
it as not few test cases already have explicit -mvsx. But AIUI
current_complier_flags requires dg-options line comes first before
the effective target line to make options in dg-options take
effect, it means we need some work to adjust line order for the
affected test cases. On the other hand, some enhancement is needed
for current_compiler_flags as powerpc_vsx (old powerpc_vsx_ok) isn't
only used in test case but can be also used in some exp check
where no expected flags exist.
3. there may be some other similar effective target checks which we
want to update as well, it means we need a re-visit on the existing
effective target checks (rs6000 specific).
4. powerpc_vsx_ok has been there for a long long time, and -mno-vsx
is rarely used in RUNTESTFLAGS, this only affects testing, so it
is not that urgent.
so I'm inclined to work on this in next stage 1. What do you think?
>
>>>> - Some test cases are updated with explicit -mvsx.
>>>> - Some test cases with those two option mixed are adjusted
>>>> to keep the test points, like -mpower8-vector
>>>> -mno-power9-vector are updated with -mdejagnu-cpu=power8
>>>> -mvsx etc.
>>>
>>> -mcpu=power8 implies -mvsx already.
>
> Then we can omit the explicit -msx option, correct? Ie, if the
> user forces -mno-vsx in RUNTESTFLAGS, then we'll just skip the
> test case as UNSUPPORTED rather than trying to compile some
> vsx test case with vsx disabled via the options.
Yes, we can strip any -mvsx then, but if we want the test case
to be tested when it's able to, we can still append an extra
-mvsx. Even if -mno-vsx is specified but if the option order
makes it like "-mno-vsx... -mvsx", powerpc_vsx is supported
so that the test case can be still tested well with -mvsx
enabled, while if the order is like "-mvsx ... -mno-vsx",
powerpc_vsx fails and it becomes unsupported.
BR,
Kewen
