rjmccall added inline comments.
================ Comment at: lib/CodeGen/CGDebugInfo.cpp:1101 case CC_AAPCS: + case CC_AArch64VectorCall: return llvm::dwarf::DW_CC_LLVM_AAPCS; ---------------- rnk wrote: > sdesmalen wrote: > > I wasn't really sure whether this requires a corresponding > > DW_CC_LLVM_AAVPCS record in LLVM, as I couldn't find much about the > > DW_CC_LLVM_ encodings, specifically whether they align with some agreed > > encoding that is implemented by GDB/LLDB. Is this defined anywhere, or is > > it ignored by debuggers at the moment? > DWARF only allows encoding 256 conventions, and we grabbed 0xC[0-F], I guess > for "clang", so we probably want to be careful about adding another. Do you > anticipate making debuggers able to call such functions? If not, it's > probably not worth it. They probably should be callable. It looks like DWARF reserves the first 64 conventions for general/language purposes and treats the rest of the range as "user" conventions. If those conventions are assumed to be universally unique, that's a really limiting schema once you started dividing it up by vendor. If I might make a suggestion, while there are certainly many calling conventions that are meant to have universal meaning (e.g. most language-specific conventions), there are also a large number that are inherently target-specific. DWARF already uses a lot of numbers that only make sense in the context of a target (like register numbers); it would make sense for DWARF to carve out a range of the encoding space (maybe 16 or 32 numbers) for target-specific CCs. This is hardly the first example; consider also all the variant ARM32 CCs or the i386 fastcall CC. https://reviews.llvm.org/D54425 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits