On Mon, Jul 12, 2010 at 9:03 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, Jul 12, 2010, Dave Martin wrote:
- Use ABI tagging (high effort, involving modifications to affected
projects - permits hardvfp ABI for explicitly selected functions)
This is the first time I hear this suggested, and it's quite a nice option
I don't understand how much effort it implies, nor what kind of adverse side effects in might have: size of binaries, compilation time perhaps?
Is the idea to select some functions to be built for each ABI, or rather build a while piece of software (with some toolchain flags) turning on the generation of the two ABIs with relevant tags on all functions taking floats as arguments? Will the toolchain be involved in taking the decision of which functions to provide for the two ABIs?
a) The easy option: tag functions internal to libraries only, leaving the library entry points unchanged.
-> only certain functions can be safely tagged - i.e., functions whose address is not passed outside the library (i.e., the "internal" ELF visibility attribute would be legal) AND which are not called in any context where a non-tagged function might be called (i.e., the tag has to form part of the function type so that a function pointer lacking the tag cannot be used to call a function which has the tag, and vice versa). Determining the taggable functions automatically may be hard. Checking automatically that the developer didn't tag any functions which weren't safe to tag may also be challenging.
-> I believe the the toolchain can automatically optimise calls to functions within the same compilation unit under some situations (including static functions). Other cases would be have to be addressed manually.
...so...
-> only the tagged functions (and corresponding call sites) will change in the build -> some manual effort to tag the functions in the affected library (the tools cannot automatically perform the procedure call optimisation between compilation units) -> probably no significant impact on compilation time -> slight reduction in code size of the library due to the shrinkage of some function call sequences (but probably not very significant)
Software which links against the library will be completely unaffected, at build, dynamic-link or run-time.
b) The harder option: allow library entry points to be tagged also.
-> may require two builds of the library, or at least a second set of external API entry points within the same library -> some code size increase to the provision of extra API entry points -> need a way to control which entry points a client project uses at build time -> ABI and packaging issues, and linker support required to manage the duplicate entry points for libraries. Some ABI interoperability issues - packages built to use the hardfp-optimised entry points will not work on platforms which don't have those entry points.
For now, (a) is probably the most practical and easiest thing to target. It's also where we might be expected to get the most benefit. (b) seems much harder - it might be worth doing for libm, but is probably not worth attempting in most other cases.
Cheers ---Dave