I see, thanks Richard S for explaining, that makes sense to me and we do 
similar things for frm.

It sounds like we need to re-visit what the semantics of vxrm is, from the spec 
I only find below words.
Does that indicates callee-save(the spec doesn't mention it but it should if it 
is) or something different? Like single-use and then discard.

I may wait a while for the official explanation.

>From spec: "The vxrm and vxsat fields of vcsr are not preserved across calls 
>and their values are unspecified upon entry. "

Pan

-----Original Message-----
From: Richard Sandiford <richard.sandif...@arm.com> 
Sent: Monday, February 17, 2025 7:48 PM
To: Li, Pan2 <pan2...@intel.com>
Cc: Jeff Law <jeffreya...@gmail.com>; Andrew Waterman <aswater...@gmail.com>; 
gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; 
rdapp....@gmail.com
Subject: Re: [PATCH v1] RISC-V: Make VXRM as global register [PR118103]

Richard Sandiford <richard.sandif...@arm.com> writes:
> The problem seems to be that mode-switching overloads VXRM_MODE_NONE
> to mean both "no requirement" and "unknown state".  So we have:
>
> static int
> singleton_vxrm_need (void)
> {
>   /* Only needed for vector code.  */
>   if (!TARGET_VECTOR)
>     return VXRM_MODE_NONE;

This was a bad example, sorry.  What matters more is that non-vector
instructions are also VXRM_MODE_NONE.  Or more specifically:

>
> and:
>
>   if (vxrm_unknown_p (insn))
>     return VXRM_MODE_NONE;
>
> This means that VXRM is assumed to be transparent in an instruction
> that matches vxrm_unknown_p.

...the function:

static int
riscv_vxrm_mode_after (rtx_insn *insn, int mode)
{
  if (vxrm_unknown_p (insn))
    return VXRM_MODE_NONE;

  if (recog_memoized (insn) < 0)
    return mode;

  if (reg_mentioned_p (gen_rtx_REG (SImode, VXRM_REGNUM), PATTERN (insn)))
    return get_attr_vxrm_mode (insn);
  else
    return mode;
}

will return VXRM_MODE_NONE if:

(a) insn is something like a call
(b) insn is a normal instruction that does not mention VXRM at all and
    mode is already VXRM_MODE_NONE

(b) is the transparent case but (a) is a kill.  Since the block walk
starts with VXRM_MODE_NONE as the initial mode, there needs to be
another mode that (a) can use to indicate a kill.

Thanks,
Richard

Reply via email to