Alex Coplan <[email protected]> writes:
> On 12/06/2026 18:14, Richard Sandiford wrote:
>> The mode of ZA is not interpreted strictly according to the usual RTL
>> semantics. That would be impossible with the current infrastructure,
>> since the number of bytes depends on the VL squared.
>
> Yeah. IIUC this is because poly_ints can (quite reasonably!) only
> represent first-order polynomials at the moment?
Right.
>> Instead, the mode
>> is supposedly just a convenience (although your question suggests it
>> might fail there).
>
> No, I haven't had a problem with this setup, it just stood out to me as
> being somewhat unusual when reviewing other SME patches. In what sense
> is it a convenience, though? Just so we know the correct element size
> from the mode used to reference ZA?
Yes. We need to distinguish .b/.h/.s/.d/.q to make the patterns unique,
but don't need to distinguish beyond that. The purpose of the mode is
purely to convey an element size.
Using the usual vector modes seemed the obvious choice for instructions
that operate on a single datatype. Having done that, using vector modes
also seemed like the obvious choice for mixed element sizes. My previous
message tried to explain why using integer modes seemed more convenient
in that case.
>> This works since ZA is a fixed register and must always be accessed by
>> unspecs that are opaque to target-independent code.
>>
>> It therefore doesn't matter whether the insn patterns use I modes or F modes.
>>
>> That being the case, there didn't seem any point in distinguishing
>> between "ZA suffixes that map to an I mode" and "ZA suffixes that map
>> to an F mode". We might as well just have one set of ZA suffixes:
>>
>> DEF_SME_ZA_SUFFIX (za8, 8, VNx16QImode)
>> DEF_SME_ZA_SUFFIX (za16, 16, VNx8HImode)
>> DEF_SME_ZA_SUFFIX (za32, 32, VNx4SImode)
>> DEF_SME_ZA_SUFFIX (za64, 64, VNx2DImode)
>> DEF_SME_ZA_SUFFIX (za128, 128, VNx1TImode)
>>
>> that map directly to the spec.
>>
>> That's the reason for not doing (2). (2) would mean either (a) defining
>> "integer ZA suffixes" and "FP ZA suffixes", or (b) encoding integerness
>> or FPness in the function_base (meaning more variations of sme_2mode).
>
> I agree that (with the current ISA) defining integer/FP ZA suffixes
> doesn't make sense. But (playing devil's advocate) couldn't
> sme_2mode_function_t just have a helper, say:
>
> /* X and Y are both vector modes. Return a vector mode that is like X
> in element size and NUNITS, but if X and Y disagree on the FPness of
> elements, make X agree with Y in this sense. */
>
> machine_mode match_fpness (machine_mode x, machine_mode y);
>
> which is then used in sme_2mode_function_t::expand (passing za_mode and
> v_mode)? I'm guessing it's not quite as simple as that, though.
We could. But it would probably need to keep the current:
if (GET_MODE_UNIT_BITSIZE (za_mode) == GET_MODE_UNIT_BITSIZE (v_mode))
za_mode = v_mode;
in order to cope with HF vs. BF. So such a change would be strictly
more code than the status quo.
Would it actually simplify any existing patterns? I would imagine that
it would instead tend to increase the number of iterators needed,
with some FP iterators that shadow existing integer iterators.
I suppose there's also the theoretical danger that a future extension
might combine FP vectors with non-FP ZA data, although I agree that
that seems unlikely.
So I'm not opposed to this change. It's just not obvious to me that
it would be an improvement for the base SME and SME2 instructions
that I remember. I haven't looked at the new extensions, so perhaps
it does ease something there.
Thanks,
Richard
