> -----Original Message-----
> From: Robin Dapp <[email protected]>
> Sent: 18 November 2025 09:04
> To: Tamar Christina <[email protected]>; Hongtao Liu
> <[email protected]>
> Cc: [email protected]; nd <[email protected]>; [email protected]; Robin
> Dapp <[email protected]>
> Subject: Re: [PATCH v2 1/3]middle-end: support new
> {cond{_len}_}vec_cbranch_{any|all} optabs [PR118974]
>
> > Hi, yeah that's right. That's a good indication I need to add that to the
> > docs.
> > Now however I only try a vector of all zeros in expand atm, mainly because I
> don't
> > know where to get the other possible else values for non-Len based targets.
> > There's a target hook preferred_else_value which different targets seem to
> > have interpreted slightly different I think.. AArch64 seems to have
> interpreted
> > it as "given a conditional operation which value is the else value" whereas
> > RISC-V seems to have done the same, but defaults to zero if the operation is
> > unconditional.
> >
> > And the default implementation is default_preferred_else_value returns 0.
>
> Just to add a little: I think the implementations of preferred_else_value (not
> mask_load_else) are aligned. aarch64 and x86 use "zeros" because that's
> what
But AArch64 does not return zero. It returns one of the operands of the
conditional
instruction.
i.e. the implementation is
static tree
aarch64_preferred_else_value (unsigned, tree, unsigned int nops, tree *ops)
{
return nops == 3 ? ops[2] : ops[0];
}
So calling this requires me to already have created the 0 operand. Which is
different
than what RISC-V does which never inspects ops and returns a value based on the
extension and mode.
> the hardware does and riscv uses "undefined" for vector types, again because
> that's what the hardware/SPEC allows.
> Using zero causes slightly less efficient riscv code because we then need to
> explicitly zero out the inactive elements. As long as we're not relying on
> those in any way (like we do in the mask load case), preferred_else_value
> should work I'd say.
Don't think it would, ops here would be 4, mask, op1, op2, default.
calling preferred_else_value on AArch64 would then return mask.
Two callers of preferred_else_value always skip the mask operand, so
They pass length -1 and &ops[1], e.g. gcc/tree-if-conv.cc and
gcc/tree-vect-stmts.cc
They would pass op1, op2, and we would return op1. Which is not a usable
default value for comparisons on the target. As the target can only zero out
inactive
lanes in compares.
Also preferred_else_value wants a conditional IFN for the first argument. We
don't
have any IFN here at all, so I can't supply a value here aside from IFN_LAST.
For RISCV the patch uses the already created VCOND_MASK_LEN that's paired with
the compare. This would already have the default value set. So it's already
been
created.
Thanks,
Tamar
>
> --
> Regards
> Robin
