carlos4242 wrote:

Thanks, that sounds like it's worth looking into and might avoid issues with 
AVR.

I'm still nowhere near enough of an LLVM expert to follow all the aspects of 
the discussion. Although from our perspective, I've never seen an issue that I 
know, using the above patch for the last few years in our LLVM back end for the 
swift compile (not in our build of clang). The code produced by the back end 
has always followed the AVR GCC ABI calling convention 
(https://gcc.gnu.org/wiki/avr-gcc ...roughly... registers assigned to 
parameters starting at r24 and working backward r22, r20, etc. to r8 then the 
rest on stack) when I have examined the generated assembly. But maybe that is 
because, until now, only our swift code has been emitted with the swift calling 
convention, until #71986 is merged, clang can't emit code with that calling 
convention and that's the issue?

Stupid question... Is it possible that our AVR LLVM back end is basically 
ignoring the swift calling convention when it actually emits our code? Doesn't 
usually the front end (clang/swift) just specify parameter types and the back 
end decides whether to put something in registers or on the stack? Sorry if I'm 
being dumb!

---

It might be that I just don't understand enough about LLVM and clang to really 
understand what all the surrounding code is doing properly, and maybe the right 
answer is for me to close this PR and wait for someone more experienced to come 
along when the time is right. We can always maintain this as a local patch in 
our builds instead, as we have for the past few years? I don't want to lay down 
issues for anyone using this in the future.

Or as an alternative, we can merge this PR as-is and deal with AVR problems 
later as an optimisation. I am neutral about what is the best approach and 
happy to take the advice of all the experts on here. (At the very least, the 
discussion has been enlightening for me!)

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

Reply via email to