"Robin Dapp" <[email protected]> writes:
>>> 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?
Could you give an example of what you mean? In the patch, it seemed
like whether a class's call_properties returned CP_HAS_ELSE or not was
a static property of the class. So rather than doing:
unsigned int
call_properties (const function_instance &) const override
{
return ... | CP_HAS_ELSE;
}
...
/* Add the else operand. */
e.args.quick_push (CONST0_RTX (e.vector_mode (1)));
return e.use_contiguous_load_insn (icode);
I thought we could instead make the interface:
rtx
function_expander::use_contiguous_load_insn (insn_code icode, bool has_else)
with has_else being declared default-false. Then use_contiguous_load_insn
could use:
if (has_else)
add_input_operand (icode, const0_rtx);
(add_input_operand should take care of broadcasting the zero to the
right vector mode.)
The caller would then just be:
return e.use_contiguous_load_insn (icode, true);
without any changes to e.args.
Is that what you tried?
Thanks,
Richard
