>> At some point here we should ensure that the else value is zero 
>> before
>> performing the replacement.  I realize it's not necessary for SVE but if
>> we have the (fixed-zero) else value like I mentioned in 7/14, we should
>> make sure here.
>
> But there's no else value to emit. The OPTAB and ifn do not have an else.
> since any non-zero else value don't make sense unless as I mentioned in
> the earlier patch you can make sure all consumer are LEN masked which
> today there is no guaranteed.

Heh, that was of coursed based on the assumption that we'd add an else 
to them, if we don't then it's moot.  Maybe let's continue under the 
assumption that COND_VEC_CMP is non-RVV and can enforce zeroing without 
target cost.

> I'm happy to drop it, but I don't think you want to replace m & cmp with a
> opaque conditional operation.  Support for VLA explicitly didn't do this as
> you lose all optimizations. i.e. {0,0, ... } & cmp is obviously {0,0, ..} and 
> such
> optimizations are important when we unroll, without this we can't remove
> dead edges.
>
> So again I'm happy to drop this, but you'd be fighting missed optimizations
> for a long time by doing this for no obvious gain to me.  I really think you
> should pick a defined else value in GIMPLE for these CFG operations.

In the RVV path today, we don't have the m & cmp but emit cmp + 
VCOND_MASK_LEN.  So there's no mask to be elided or optimized.

Somewhat related but not to the RVV case: Why can't 
try_conditional_simplification and friends optimize {0,0, ... } & cmp 
(with cmp being an IFN)?  Shouldn't it, conceptually, even if actual 
support is missing?

-- 
Regards
 Robin

Reply via email to