mbox series

[0/5] Fix fmv mangling for AArch64

Message ID db8b5080-2f2f-64c9-456e-c8553b16d677@e124511.cambridge.arm.com
Headers
Series Fix fmv mangling for AArch64 |

Message

Andrew Carlotti Jan. 15, 2024, 11:26 a.m. UTC 
  This patch series should have no functional change besides the mangling of some symbol names on AArch64.

Patch 1/5 adds lots of tests to verify that existing mangling behaviour on x86 and PowerPC is unchanged.

Patch 2/5 extends DECL_FUNCTION_VERSIONED to a 2-bit enum.

Patches 3/5 and 4/5 are trivial refactorings.

Patch 5/5 is the only patch with any functional change, and that should be
minimal.  I've bootstrapped and tested the entire series on both AArch64 and
x86.  I've also run the new x86 and PowerPC tests on a cross-compiler (with a
temporary hack to disable ifunc availability checks) to verify that function
multiversioning still works on those platforms, with the symbol mangling
unchanged.

I'm aware now that we just started of Stage 4, and this isn't actually a
regression, but is this still ok for master?



Some other things I previously tried that I couldn't make work:
- I had hoped to create an explicit target hook for the ifunc symbol name
mangling as well, but it turned out to be rather tricky to replicate the
existing double mangling weirdness for x86 (I didn't work out how to convince
the frontend to apply C++ mangling to the new symbol on-demand without breaking
other things).

- It's also awkward to try to access the base assembler name after applying
function version mangling - this is why I resorted to just reversing the
default version mangling in the AArch64 backend.  I tried delaying function
version mangling until after the resolver was generated, but that led to issues
with duplicate comdat group names from make_decl_one_only.

There may be less hacky solutions or workarounds for these issues, but they
would involve a more substantial refactoring and will have to wait until GCC 15
(or later).