- User Since
- Dec 9 2012, 11:41 PM (244 w, 5 d)
Wed, Aug 16
Tue, Aug 15
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.
Mon, Aug 14
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?
Sun, Aug 13
Yeah, I think that this is okay.
Sat, Aug 12
Please adjust the comment and remove the CMake change prior to committing this.
Sat, Aug 5
Please create a special GNU specialization for this.
Wed, Aug 2
Tue, Aug 1
Might be a good idea to add tests for the IR itself that we lower it properly.
Sun, Jul 30
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.
Sat, Jul 29
Fri, Jul 28
Thu, Jul 27
Does anyone use the overload with the O for exports with nullptr instead of this? If not, we could just inline this throughout.
Wed, Jul 26
Tue, Jul 25
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.
Sat, Jul 22
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.
Fri, Jul 21
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.
Jul 19 2017
Jul 18 2017
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.
Jul 16 2017
Please fix the relocation type before you commit this.
Jul 13 2017
Jul 10 2017
Jul 4 2017
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.
Jul 3 2017
Jun 30 2017
Jun 29 2017
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!
Jun 28 2017
Jun 27 2017
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.
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.
Jun 26 2017
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.
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.
Jun 25 2017
Some more comments, add test case.
I can add the nested/nested classes. What were other nested concepts you thinking of?
Jun 24 2017
Address feedback. Also fix the case that was previously not working. This now covers all the various cases that have been discussed.
Jun 23 2017
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.
Jun 22 2017
@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?