More Flexible ABI Support

[daveedvdv-nvidia]

Currently, the EDG front end supports two major ABIs, each with some minor variations: Cfront-based ABIs when the configuration macro IA64_ABI is false and Itanium-based ABIs when that macro is true.  With an eye toward eventually improving MSVC ABI compatibility, I'd like to first reorganize the ABI-handling code such that:

• the code is not (only) selectable by preprocessor configuration (e.g., it should be possible to have a single executable implementing both ABIs — useful, e.g., for testing), and
• it is more modular so that it becomes fairly clear how to add a new ABI.

I've started sketching this out:

1. Scope: All of src/ code — front-end semantics, class layout, IL, name mangling (lower_name.c), IL lowering (lower_il.c, lower_init.c, lower_eh.c), and the C-generating back end (c_gen_be.c). lib_src/ remains build-time configured via the __EDG_* macros emitted by macro.c.
2. Don't split .c files by ABI: Keep existing translation units intact (layout.c, class_decl.c, lower_name.c, lower_il.c, lower_init.c, lower_eh.c, c_gen_be.c). Use a runtime ABI descriptor/traits struct (an_abi_config curr_abi;) combined with in-file modular helpers and per-ABI dispatch tables.
3. Preserve existing compatibility features dynamically: Retain ABI_COMPATIBILITY_VERSION, CFRONT_*_COMPATIBILITY, and ABI_CHANGES_FOR_* semantics, moving them from preprocessor #if conditionals to tests of fields in curr_abi.

I expect this will (unfortunately) cause some significant churn throughout the codebase.

[wchilders-nvidia]

It might be worth trying to make the class/variable representing the ABI target (as a configuration option) a constexpr variable so that optimizers can more easily strip branches if a binary only cares about a particular ABI. For instance if ABI_TARGET is nothing it would be runtime dependent, if ABI_TARGET is cfront it would enter a constant for cfront and be compile-time locked-in.

We've talked about plumbing more compiler state as a class that's passed around instead of a global variable; that might be worth exploring ... but I suspect it's a secondary concern and would make the above more complicated.

[daveedvdv-nvidia]

Yes, that's a good option. So maybe one or more DEFAULT_... macros that select the default ABI, and a separate macro to "lock in" that default (thereby also disabling the ability to select a different one on the command-line).