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.
Details
Diff Detail
Event Timeline
test/CodeGen/MSP430/cc_args.ll | ||
---|---|---|
55 | Third argument should be back-filled into r13 register, as per section 3.3.4 of EABI. |
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)
This change looks good, but I don't have any rights to accept it, sorry. We'll have to wait for aKor to review it, you can try to ask him on irc if you see him.
lib/Target/MSP430/MSP430ISelLowering.cpp | ||
---|---|---|
248 | 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 | Minor nit: I'd prefer += 1 here. | |
324 | Minor nit: I'd prefer -= 1 here | |
328 | Please follow LLVM's coding style : no newline before "else if" / "else" | |
570 | No braces |
Sorry for being pedantic, but your new diff adds a lot of trailing spaces to the code.
Updated diff to hopefully address @pftbest's concerns about whitespace - I wasn't totally sure what you were pointing to but there's now no trailing whitespace in any of the code files that are modified by this patch.
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.
Sorry, not the vararg test, but this 3 tests:
CodeGen/MSP430/2009-08-25-DynamicStackAlloc.ll
CodeGen/MSP430/2009-12-22-InlineAsm.ll
CodeGen/MSP430/cc_ret.ll
lib/Target/MSP430/MSP430ISelLowering.cpp | ||
---|---|---|
252 | Is there any guard preventing calling this function when we're having zero args? |
Somehow managed to run check-all against an old version. Added obviously-required check for an empty vector. All tests now pass (and don't segfault).
LGTM with small change aboce
lib/Target/MSP430/MSP430ISelLowering.cpp | ||
---|---|---|
253 | Simple early return here. |
Looks like D29916 broke this patch. Also CanLowerReturn should be marked with override to prevent compile warnings.
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?