[LLVMdev] Passing return values on the stack & storing arbitrary sized integers

Eli Friedman eli.friedman at gmail.com
Thu Aug 16 10:42:56 PDT 2012


On Thu, Aug 16, 2012 at 5:18 AM, Fabian Scheler
<fabian.scheler at gmail.com> wrote:
> Hi everybody,
>
> thanks to kind help of the LLVM-community I was able to bring my
> TriCore back-end a huge step forward, however I am not done, so far. I
> still miss the following features and maybe you could again provide me
> some help:
>
> 1. Passing return values on the stack
>
> Describing the calling conventions in tablegen so that first registers
> are used and to fall back to the stack if these do not suffice.
> However, this is not enough and lowering calls and returns have to
> reflect this, too.  Currently, most targets also do not support this
> (there is assertion: assert(VA.isRegLoc() && "Can only return in
> registers!")).
>
> How important is this feature? Is it save to ignore it? Is there some
> guide how to implement such a hybrid passing of return values (partly
> in registers, partly on the stack)? Currently, the TriCore back-end is
> not able to compile functions returning e.g. {i128,i1}.

This isn't very important; you won't run into it compiling C code.

> 2. Storing arbitrary sized integers
>
> The testcase "test/CodeGen/Generic/APIntLoadStore.ll" checks for
> loading/storing e.g. i33 integers from/into global variable. The
> questions are the same as regarding feature 1: How important is this
> feature? Is it save to ignore it? Is there some guide how to implement
> this?

If you're using the LLVM CodeGen infrastructure and have everything
else implemented correctly, this should be taken care of for you.  We
have infrastructure generally referred to as "legalization" that will
transform this into something sane for your target automatically.  I
would suggest not ignoring this because the optimizers will
occasionally generate unusual loads and stores.

> When looking for some kind of guide, I am not looking for step-by-step
> instructions to implement these issues, but a well documented back-end
> would be really helpful, here. While being the most complete target,
> the X86 target IMO is much too complex for that purpose.
>
> BTW: are the testcases in test/CodeGen/Generic supposed to be
> "must-haves" for all LLVM-targets or can/should I ignore some of them?

How important they are probably depends on your target... it's really
a grab-bag of unrelated tests which hasn't been updated in a long
time.  If any of them crash, though, it's probably worth looking into.

-Eli



More information about the llvm-dev mailing list