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
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
