[llvm-dev] target ABI: call parameters handling

[Ulrich Weigand via llvm-dev]

Ulrich Weigand/Germany/IBM wrote on 29.09.2021 20:54:00:
> "Reid Kleckner" <rnk at google.com> wrote on 29.09.2021 20:35:09:
>
> > 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.

That said, of course you're right that using some extension by
default is "safer" in the sense that it'll just do the right
thing in more cases than simply not extending at all.

So maybe one option might be to implement Jonas' original idea
of an abort unless the parameter is marked either zeroext or
signext or anyext, but only under control of a command line
option enabling "strict checking".  This would be off by default,
in which case the back-end would default to some extension
as per your suggestion.

The strict option could be on e.g. for the buildbot jobs, so
we'd at least have a good chance of catching missing extensions
in code that's part of the LLVM repo and checked by the bot.

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