carlos4242 wrote: > This is less about the implementation weeds of LLVM and more about the actual > details of your calling convention — the decisions about how arguments and > results are passed that are ultimately downstream of the choices made here. > Mostly, I'm encouraging you as a platform maintainer who's adding Swift CC > support for your platform to take a few moments to make sure you're happy > with the CC. It's likely that everything will _work_ regardless — Swift will > generate both declarations and calls according to the rules of the CC you > specify here, which should be enough to make things functional — but you > might find yourself looking at generated code in two years and realize you've > been doing something ridiculous for that entire time, and maybe it'll be too > awkward to change.
That makes a lot of sense. Thank you John. I guess here are my thoughts. As I understand it, the `SwiftABIInfo` by default does something like "if something can be passed in 4 registers or fewer then pass by register, otherwise pass indirectly"? I think that sweet spot (also sort of reflected in Existential Containers I believe?) makes sense for 32 bit or 64 bit registers (and presumably the sorts of caching you'd expect in modern intel/arm larger machine architectures). We have 8 bit registers, which is quite different... Thinking aloud... In our case, one complication is stack manipulation is fairly painful, we may be able to improve the AVR back end a bit but at the moment, just moving the stack pointer down for something like an alloca is 8 instructions (and then again 8 bytes in the function epilog). But, equally, the default C ABI (avr gcc abi) allows a struct to be split over as many as 18 registers, and we are often producing pretty inefficient code like this when we have large structs, moving registers around a lot either side of a call site. Which is something I really wanted to find a way to solve "one day" with Swift for Arduino/Microswift/Swift for AVR. Probably it's reasonable to say that ideally, when lowering to AVR assembly from Swift, any struct larger than 8 bytes should be passed on the stack in our case. Do you think we can implement that? I'm happy to do some AVR back end work to change the ABI when the swift calling convention is in place on a function. (Although it might have to wait until I've had time to get the new Embedded mode working on our Swift compiler first, as that's taking up most of my time for the moment.) 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
