rjmccall wrote:
> @efriedma-quic Cool. So it sounds like it's worth parking this for now, until
> Kuba's work #71986 is merged?
>
> @rjmccall I'm not 100% sure I understand? The existing code in AVR.cpp
> handles the standard AVR ABI, which has a few simple rules based on GCC
> behaviour. Here we are effectively just passing on the handling for that to
> `AVRABIInfo`. The error in register thing, I just copied what ARM is doing. I
> figure that's OK for now. If we need to do some bugfixes later to get AVR
> working with errors then we'll take a look then probably. Is that reasonable?
`SwiftABIInfo` exists so that targets can tweak more details than just whether
to use `swifterror`. For example, you can change the conditions under which
we'll try to return things in registers, and if you don't do that, IIRC Swift
will try to return quite a few things in registers by default. I'm just saying
that you should make sure that that matches with your backend — either your
backend needs to make sure that it returns a type like `{ ptr, ptr, float,
float }` in registers for `swiftcc` or you should tweak the frontend so that it
knows to return it directly.
https://github.com/llvm/llvm-project/pull/72298
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
