[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D84602#2178328 <https://reviews.llvm.org/D84602#2178328>, @atrosinenko wrote:

> In D84602#2176592 <https://reviews.llvm.org/D84602#2176592>, @aaron.ballman wrote:
>
>> To be clear, I also don't have a problem with it, but if users aren't supposed to be writing this attribute themselves and if we can apply the calling convention from markings in a .def file instead, I think it could be a cleaner approach to go that route instead. There's a lot of "ifs" in that sentence though. :-)
>
> Do you mean detecting these functions by their names, like GCC does? If so, that trick would replace all the
>
> - D84602: [MSP430] Expose msp430_builtin calling convention to C code <https://reviews.llvm.org/D84602>
> - D84605: [IR][MSP430] Expose the "msp430_builtin" calling convention to .ll <https://reviews.llvm.org/D84605>
> - D84636: [RFC] Make the default LibCall implementations from compiler-rt builtins library more customizable <https://reviews.llvm.org/D84636>
>
> ... provided this is considered as a generally suggested solution across the codebase, not a hack :)

I was envisioning specifying the builtins in a .def file like we do with other builtins, but allowing that .def file to specify optional calling convention information on a per-function basis (like we already support other attributes). So there would still be an LLVM attribute to be used, but there would not be a user-facing Clang attribute that users could misapply to their own code. So the attribute definition here would continue to exist, but the attribute would have no spelling associated with it. We do this with some other attributes, like `AlignMac68kAttr` or `MaxFieldAlignmentAttr`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84602/new/

https://reviews.llvm.org/D84602