On AArch64, s128 types have to be split into s64 GPRs when passed as arguments. This change adds the generic support in call lowering for dealing with multiple registers, for incoming and outgoing args. Support for splitting for return types not yet implemented.
IIUC calling convention specified register splits should be generic, and it's handled in generic code by SelectionDAG. Whether handleAssignments is the best place for I'm not sure, but I don't think targets should have to deal with this individually. In arm64 I think we already have some target call lowering code that should really be generic.
obligatory braces nit
I think a high-level explanation of what we're going to do when we have an incoming vs outgoing handler would be useful.
Can we have a comment here explaining what's going on?
I think that this could use a comment too.
Why less than 2?
Pull Args[I].Regs.size() into a variable with a meaningful name?
Why are we falling back now?
Because this is a code path that hasn't been implemented or tested yet. That is, if we're dealing with an outgoing arg, and we failed to assign a location (at the beginning of handleAssignments), and the calling convention says it doesn't need to be split (NumParts < 2), then we don't know what else to do.
We're not, I'm just adding this flag to ensure we error if we do fall back at all.
It looks like you only use the ability here to change elements, not add/remove them? I think that's a MutableArrayRef use-case.
It looks like you only modify elements in place? If so, that's MutableArrayRef's thing.
Why only setSplit for outgoing args?