Nice! Im looking forward to this! It was one of the bits that I hadn't gotten around to implementing just yet, so thanks for taking it on.

Um, when LLVM makes the invocation, it will assume that s0/s1 are not clobbered, even though it is a function call. Shouldn't we be explicitly saving and restoring s0/s1 in the ARM HF cases?

Yeah, I think that this is okay.

Please adjust the comment and remove the CMake change prior to committing this.

Please create a special GNU specialization for this.

Might be a good idea to add tests for the IR itself that we lower it properly.

Right, I realize that it is only needed for the compiler-rt case, but I think it simplifies the flow and makes the behaviour similar across the two branches.

Does anyone use the overload with the O for exports with nullptr instead of this? If not, we could just inline this throughout.

I think that the approach is reasonable. However, the test needs tweaking. The function and the call both are ambiguous in the match. Can you match the call sequence? Or explicitly the local label and then the call.

Please split this out into arm64intr.h and include it from intrin.h under a #if defined(_M_ARM64) case before committing.

You should be able to generate an object file with the imgrel relocation.

Does link actually set the ISA selection bit on the EAT entries? I don't remember that behaviour from it and I dont have it on hand to check.

Forwarders on Windows are roughly the equivalent to a re-export library. They aren't exactly the same thing as you need to list all the interfaces instead of saying all interfaces from this library.

I wish that we could add a test for this. Unfortunately, libunwind as it stands doesn't do a very good job with tests :-(. Thanks for cleaning up the change and fixing this.

Can you please add a test that shows that the AEABI functions are not given the wrong CC? Also, can you show that if someone also passes -meabi=gnu with a VFP target, that we still annotate the functions with the differing CC (since that should prefer the GNU functions over the AEABI functions).

Thanks, this looks like a good cleanup.

Please fix the relocation type before you commit this.

In D34588#802533, @bruno wrote:

Thinking more about this, on Windows, is there a strong reason to default to a different libc by default on Windows?

I'm mostly concerned with -fms-extensions + darwin, which doesn't apply to this scenario, maybe someone else knows a better answer here.

The generation of the soft float calls to the GNU division routines is for compatibility. GCC will generate soft float calls unless the target is marked as hf. So, we should adjust the triple that we use (-target armv7-unknown-none-eabihf -meabi=gnu should do the trick I believe). GCC's handling of the ABI here is really rather annoying since -target armv7-unknown-none-eabi -meabi=gnu -mfloat-abi=hard will generate soft float calls to the routines, but -target armv7-unknown-none-eabihf -meabi=gnu -mfloat-abi=soft will generate hard float calls. However, we need to emulate the silly behaviour for compatibility.

Please trim down the test. I dont think that any of the debug info metadata is needed to validate the CPE is coalesced nor are the attributes.

I'm still not sure I understand why we need the different CC when X86_64 is able to handle both the SysV and the MS style VAArg lowering via the ABI::LowerVAArg switching between the two. I feel that we should follow a similar approach here.

SVN r306829

Would it be possible to use YAML and yaml2obj to create the test input?

Please add tests for the other relocation types.

Can you please double check the type of long double as well?

This seems like a good idea. Thanks!

Please add a check for the incremental link compatible flag.

I don't think that we should be adding a new calling convention for this. Win/AArch64 is just AAPCS64. Just like ARM, the difference for the va_list can be abstracted out entirely in the frontend, even if it is through a new LLVM intrinsic.

SVN r306444

Discussed with @thakis on IRC; we can go ahead with this, but this will change in the future to be conditionalised on whether you are building a static or shared library. The intention here is to build without the exports and maintain hidden visibility. Although this is different from libc++, it is due to the fact that the current libunwind interfaces dont make as much sense on Windows (the itanium model and the windows exception model are thoroughly different), so removing the visibility attributes doesn't make much sense.

Thanks for cleaning this up.

Thinking more about this, on Windows, is there a strong reason to default to a different libc by default on Windows? @bruno would reusing -ffreestanding work for you here? Or is there something else that we can identify about the target environment that can indicate that the MS CRT is unavailable? I think that what is weird to me about this is that this is not about compatibility with Visual Studio but about the underlying libc. It feels like it would be similar in spirit to say that libc++ defaults to libSystem as the underlying libc on Linux.

SVN r306347

Handle unnamed parameters, improve mangling for NSDMis. The one case that we dont handle currently causes an assertion even in itanium mode.

__ptr64 mangling, add tests for 32-bit.

Some more comments, add test case.

I can add the nested/nested classes. What were other nested concepts you thinking of?

Use mangleSourceName

Address feedback. Also fix the case that was previously not working. This now covers all the various cases that have been discussed.

Ah, thanks for the explanation @efriedma.

This is a step in the right direction. Although the NSDMI cases and default parameter value cases are not yet handled, they break due to tracking of the global mangling number tracking, not due to the scheme.

@efriedma I think that Im still not understanding the case that you are trying to point out. How do we end up in a state where the block invocation function is referenced external to the TU? The block would be referenced to by name of the block, no? AFAICT, this is for local storage in a block, which is scoped to the block invocation function, which is TU local, and will be referenced by the block_literal (which contains the block invocation function and is dispatched via the BlocksRuntime).

@efriedma which bit of the Itanium mangling should I be looking at? A BlockDecl does not have visibility associated with them, so Im not sure what I should be checking to see if the block is visible or not. What is the best way forward for finishing this up?

Add additional test cases, improve coverage and mangling.

@efriedma hmm...using getBlockManglingNumber causes the name to be duplicated. Ill look into that. However, wouldn't all the block invocation functions be defined and COMDAT'ed?