[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