Hi!
on 2022/10/19 00:52, Segher Boessenkool wrote:
> Hi!
>
> On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote:
>> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote:
>>> It did not happen in GCC 9 obviously. Do you want to take a
>>> shot? It
>>> doesn't have to be all at once, it's probably best if not even -- as
>>> I
>>> wrote in the commit message, the flag always was used to mean
>>> different
>>> things.
>>
>> As long as it's OK to be removed, I'll certainly take a shot at it.
>
> It is. Thanks!
>
>> With that in mind that may simplify things for me here.
>> I expect that
>> anything currently guarded by DIRECT_MOVE should instead be guarded by
>> POWER8.
>
> Yes. Which works just as well for the places that actually check
> whether the direct move insns can be used, and for everything else that
> wants p8 :-)
>
IIUC, this discussion is saying we want to replace all TARGET_DIRECT_MOVE
with TARGET_POWER8? I may miss something but it sounds wrong to me.
Currently TARGET_DIRECT_MOVE is used to guard many places which rely on
vector (VSR) support. One example is one place quoted from [1]:
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index e226a93bbe55..be4fb902049d 100644
> --- a/gcc/config/rs6000/vsx.md
> +++ b/gcc/config/rs6000/vsx.md
> @@ -3407,11 +3407,11 @@ (define_insn "vsx_extract_<mode>"
> if (element == VECTOR_ELEMENT_SCALAR_64BIT)
> {
> if (op0_regno == op1_regno)
> return ASM_COMMENT_START " vec_extract to same register";
>
> - else if (INT_REGNO_P (op0_regno) && TARGET_DIRECT_MOVE
> + else if (INT_REGNO_P (op0_regno) && TARGET_POWER8
> && TARGET_POWERPC64)
> return "mfvsrd %0,%x1";
Now we want TARGET_POWER8 still on if users specify -mcpu=power8 -mno-vsx,
if we guard the above with TARGET_POWER8, it would mean we can still
have "mfvsrd" but it shouldn't be available as it relies on VSX support
which gets disabled explicitly. So for these kinds of uses of
TARGET_DIRECT_MOVE which are for actual "direct move" insns, they should
be guarded with TARGET_P8_VECTOR instead?
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603724.html
BR,
Kewen
