>> For the lack of a better idea I used a function call property to specify >> whether a builtin needs an else operand or not. Somebody with better >> knowledge of the aarch64 target can surely improve that. > > Yeah, those flags are really for source-level/gimple-level attributes. > Would it work to pass a new parameter to use_contiguous_load instead?
I tried this first (before adding the call property) and immediate fallout from it was the direct expansion of sve intrinsics failing. I didn't touch those. Should we amend them with a zero else value or is there another way? > Splitting the patterns is the right thing to do, but it also makes > SVE_PRED_LOAD redundant. The pattern above with the else operand > should use UNSPEC_LD1_SVE in place of SVE_PRED_LOAD. The version > without should use UNSPEC_PRED_X (and I think can be an unnamed pattern, > starting with "*"). > > This would make SVE_PRED_LOAD and pred_load redundant, so they can > be removed. The caller in svld1_extend_impl would no longer pass > UNSPEC_LD1_SVE. > > Sorry about the churn. Matching the load and move patterns in one go > seemed like a nice bit of factoring at the time, but this patch makes > it look like a factoring too far. Thanks, this appears to work.
