[RFC, WIP] Allow overriding some basic parameters of generic C LibCall implementations

[atrosinenko]

Background:

• builtins library from compiler-rt has portable default implementations written in C for all its LibCalls
• those implementations can be replaced by potentially much efficient target-specific ones when appropriate
• ideally, one should be able to start with all-default implementations ASAP when adding support for a new target

Problem statement:

• some targets have special requirements on LibCalls:
  • name aliases (see ARM-specific aliases in mainline compiler-rt, MSP430 requires some as well)
  • seemingly arbitrarily chosen calling conventions (see part 6.3 of MSP430 EABI document). While they are probably justified by implementation specifics, it is hard to deduce the required convention merely from the signature (harder than just "special iff is LibCall and has two 64-bit arguments")
  • the default implementation (that potentially is already quite elaborate) may perfectly fit all the requirements apart from those tiny configuration details
• it is worth not to force target implementations to diverge from the upstream ones just to account for such tiny differences
• on the other hand, it is worth to not clobber the generic implementation with a bunch of target-specific defines
• the third useful feature is catching as much errors at compile-time as possible
• this problem blocks #21 as it may be hard to pass a review with lots of local adjustments to calling conventions
  • I have no strict preference on how this should be achieved, I just have a proposal on one of the ways this can possibly be done

This proposal:

• - has large patch size
  • + is by design a one-time refactoring simplifying adding new targets in the future
  • + can already help factoring out the existing ARM-specific name aliases
  • most of the changes was performed automatically by sed, so they (and their corresponding scripts) can be reviewed separately while spending most of the time on manual changes
• - has a shell script that may need re-running from time to time
  • it is not required to have bash on every system that will just compile LLVM since the resulting header is expected to be committed to the repository
  • there already exist some scripts under compiler-rt/utils that generate some headers for NetBSD
  • - there is a possibility that someday someone will forget to re-run it
  • + most probably, the only cases when it is actually required are
  • adding some new LibCall
  • changing the set of tunables (now, there exist two: "calling convention" aka "misc attributes" and "name aliases" aka "misc footer")
  • + it seems to have much simpler requirements on how to run it than some of those NetBSD-related scripts :)
  • - more real-world mistake would probably be to make a simple change (such as adding one another generic source file) and updating the autogenerated header manually because it was so trivial change, so when the script will be eventually re-run, there would be some unexpected changes
  • + because the script has very weak assumptions on how it should be run, we can just have a test (that requires bash) that ensures that the committed script and the committed header match
• + all adjustments listed above (calling conventions, name aliases) will be contained inside a single target specific header and a couple of lines in int_lib.h that conditionally #include that header
• + when something was made wrong, chances are high it would be caught early
  • declaring a new LibCall via DECLARE_LIBCALL macro without updating the script immediately triggers a compilation error
  • - on the target implementation side, there are no safety nets, so one can easily mistype a LibCall name in a statement like #define AUX_DECLS__ashldi3 ... that would be silently ignored by this infrastructure
  • there is a chance this would be caught by target-specifc tests and debugged and fixed early by the same person who is implementing that target's support (at least, when changing calling convention)
  • the most care should probably be taken when reviewing this particular initial implementation, as I have to "import" the existing ARM-specific aliases

[atrosinenko]

Sent for public discussion: https://reviews.llvm.org/D84636.