[llvm-dev] target ABI: call parameters handling

[Ulrich Weigand via llvm-dev]

"Reid Kleckner" <rnk at google.com> wrote on 29.09.2021 20:35:09:

> I don't think it would be reasonable for the SystemZ backend to
> abort every time it is asked to code generate an i32 argument that
> lacks an attribute. There are simply too many IR producers
> (frontends and instrumentation tools) that will pass unannotated i32
> values to calls. It's not feasible to fix them all, and aborting
> just means these producers will have to be updated whenever they are
> ported to SystemZ or any other target adopting the same practice.
>
> I think it would instead be reasonable to pick a safer default for
> the target, like always zero extending unannotated parameters on
> both the caller side and the callee side. This is less efficient
> than only extending once in the caller, but it makes it much easier
> to retarget an IR producer over to SystemZ. It makes the attributes
> into performance improvements, not correctness requirements. I
> suspect this will not actually break passing a 4 byte struct, it
> just makes it less efficient.

Unfortunately there is no "safe" default.  If the callee expects
a signed value, the argument has to be sign-extended; if the
callee expects an unsigned value, the argument has to be zero-
extended.  Using the wrong extension is just as much a codegen
bug as not extending at all.

E.g. if the callee expects an "int" argument in a register,
which is then used as index in a (64-bit) address, generated
code may use that register without explicit extension, assuming
the caller already sign-extended the value.  If the caller
passes -1, and wrongly zero-extends instead of sign-extending,
the resulting address will be wrong.

> As for the suggestion to add an explicit structarg attribute, can
> this be generalized to an attribute that marks the high bits as
> undef? So, IR producers will have a portable way to explicitly
> request the current behavior. This is kind of like `anyext`, but not
> really, more like `undefext`, `uext`, `hiundef` or `calleemustextend`.

Agreed, this would be more general.

Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210929/4a81d393/attachment.html>