[PATCH] D56297: [DWARFUnit] Don't assume basic types.
Paul Robinson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Jan 4 14:40:52 PST 2019
probinson added a comment.
In D56297#1346801 <https://reviews.llvm.org/D56297#1346801>, @andrewrk wrote:
> So it looks like I should modify the frontend to represent this as a DerivedType with a baseType=SubroutineType. Is that right?
A DerivedType that's a pointer, yes. If that accurately describes your source.
================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:472
+ if (!BTy)
+ return false;
unsigned Encoding = BTy->getEncoding();
----------------
andrewrk wrote:
> davide wrote:
> > aprantl wrote:
> > > Why is false the right answer here?
> > To be quite honest, I think it's irrelevant (in the sense that it doesn't matter what we return here).
> It seems to me that the question "is a subroutine an unsigned type" is a nonsensical question, and should be an assertion error (as it is in status quo trunk).
>
> Or otherwise if a subroutine can be treated implicitly as a pointer, then it should have the same answer that a pointer would have, which is `true`.
I agree that asking whether a subroutine type is an unsigned type makes no sense. All contexts where we call isUnsignedDIType() are about emitting constant values. Why are we asking about a subroutine type?
================
Comment at: llvm/test/Assembler/DIAsmunsigned.ll:2
+; RUN: llc < %s | FileCheck %s
+; CHECK: .section __DWARF,__debug_str,regular,debug
+; CHECK-NEXT: Linfo_string:
----------------
This looks like Darwin naming, you probably want an explicit triple on the RUN line.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56297/new/
https://reviews.llvm.org/D56297
More information about the llvm-commits
mailing list