On Sat, 29 Apr 2023 10:21:53 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
On Sat, Apr 29, 2023 at 8:06 AM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
On 4/28/23 20:55, Li, Pan2 wrote:
> Thanks Jeff for comments.
>
> It makes sense to me. For the EQ operator we should have CONSTM1.
That's not the way I interpret the RVV documentation. Of course it's
not terribly clear. I guess one could do some experiments with qemu
or try to dig into the sail code and figure out the intent from those.
QEMU specifically takes advantage of the behavior Andrew is pointing out
it the spec, and will soon do so more aggressively (assuming the patches
Daniel just sent out get merged).
Does this mean s390 parts has similar issue here? Then for instructions
like VMSEQ, we need to adjust the simplify_rtx up to a point.
You'd have to refer to the s390 instruction set reference to understand
precisely how the vector compares work.
But as it stands this really isn't a simplify-rtx question, but a
question of the semantics of risc-v. What happens with the high bits
in the destination mask register is critical -- and if risc-v doesn't
set them to all ones in this case, then that would mean that defining
that macro is simply wrong for risc-v.
The relevant statement in the spec is that "the tail elements are always
updated with a tail-agnostic policy". The vmset.m instruction will cause
mask register bits [0, vl-1] to be set to 1; elements [vl, VLMAX-1] will
either be undisturbed or set to 1, i.e., effectively unspecified.
jeff
