This patch adds support for struct return values to the MSP430 target backend. It also reverses the order of argument and return registers in the calling convention to bring it into closer alignment with the published EABI from TI.
Updated patch to correctly backfill registers when "holes" are created by 64-bit arguments (EABI section 3.3.4) and to split 32-bit arguments when only one free register remains (EABI section 3.3.3)
|248 ↗||(On Diff #85630)|
I'm a bit confused by logic here. Is there any reason why we shouldn't simply count from 0 here? Could also switch to range-for while here?
|252 ↗||(On Diff #85630)|
Minor nit: I'd prefer += 1 here.
|324 ↗||(On Diff #85630)|
Minor nit: I'd prefer -= 1 here
|328 ↗||(On Diff #85630)|
Please follow LLVM's coding style : no newline before "else if" / "else"
|570 ↗||(On Diff #85630)|
Whitespace is gone, thank you.
Also I did some testing: compiled llvm with expensive checks on and address sanitizer, found no issues.
Compiled a non-trivial program and ran it on CC430 MCU, it worked fine.
So this patch LGTM
As I see it, CurrentArgIndex is overloaded with two (or more) tasks, so the code is confusing. Maybe it would be better if CurrentArgIndex was just a counter, and the other conditions can be handled by introducing boolean flags, for example.
The problem with ParseFunctionArgs was that it was being too clever with initializing CurrentArgIndex. It used to initialize to UINT16_MAX because that was "one less than" the first Arg's OrigArgIndex, but now that we have srets we can get NoArgIndex which happens to be UINT16_MAX. I originally tried to preserve the structure of the loop but now it just explicitly initializes instead of being clever.