[LLVMdev] debug info for llvm::IntrinsicInst ???

[David Blaikie]

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote:

>  Ok.
>
> I'm basically just following the model of the other fast-isel ports.
>

Yeah, not your fault - just an architectural quirk.

It's possible we could workaround the debug info side of this by declaring
the virtual dtor (or some other virtual function - even an explicit anchor
as we have in some other places) and defining it out of line.


>
>
> On 01/30/2015 09:12 PM, David Blaikie wrote:
>
> (I'm assuming you're building LLVM with clang, in this case?)
>
> Looks like IntrinsicInst is one of those "lies" in LLVM that works via
> type punning that's undefined behavior in C++, so it's code that should be
> fixed anyway.
>
> In any case, the reason this produces the debugging experience you're
> seeing is that LLVM (& GCC, for that matter) assumes that if your class has
> virtual functions, such as IntrinsicInst, here - then to use the type one
> must've emitted the vtable for the type somewhere (the C++ standard
> requires this - if you odr use the type, all the virtual functions must be
> defined somewhere in the program). The debug info emission attempts to
> reduce the number of times the debug info for the type is emitted by
> piggybacking on this fact - producing the type definition only where the
> vtable is produced.
>
> As it turns out, with this class, the vtable is never emitted. This is
> because the type has no key function (no non-inline virtual function) and
> the ctor itself is never emitted, so the vtable is never needed... and thus
> no debug info.
>
> The right way to fix this is to stop relying on undefined type punning -
> though I don't know enough about the APIs here to say just how to achieve
> that goal.
>
> On Fri, Jan 30, 2015 at 8:55 PM, reed kotler <rkotler at mips.com> wrote:
>
>> When trying to display and do anything with a variable of type
>> IntrinsicInst, gdb thinks that it's an incomplete
>> type and kind find any member functions or even display the class.
>>
>>
>>
>>
>> (gdb) list 1337
>> 1332
>> 1333      // Finish off the call including any return values.
>> 1334      return finishCall(CLI, RetVT, NumBytes);
>> 1335    }
>> 1336
>> 1337    bool MipsFastISel::fastLowerIntrinsicCall(const IntrinsicInst
>> *II) {
>> 1338      switch (II->getIntrinsicID()) {
>> 1339      default:
>> 1340        return false;
>> 1341      case Intrinsic::bswap: {
>> (gdb) print II
>> $10 = (const llvm::IntrinsicInst *) 0x61b8ec8
>> (gdb) print *II
>> $11 = <incomplete type>
>> (gdb) call II->getIntrinsicID()
>> Couldn't find method llvm::IntrinsicInst::getIntrinsicID
>> (gdb)
>>
>>
>> However, up the call tree:
>>
>> (gdb) frame 3
>> #3  0x000000000368db6d in llvm::FastISel::selectOperator (this=0x6235290,
>>     I=0x61b8ec8, Opcode=49)
>>     at
>> /home/rkotler/workspace/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp:1535
>> 1535        return selectCall(I);
>> (gdb) list 1535
>> 1530
>> 1531        // Dynamic-sized alloca is not handled yet.
>> 1532        return false;
>> 1533
>> 1534      case Instruction::Call:
>> 1535        return selectCall(I);
>> 1536
>> 1537      case Instruction::BitCast:
>> 1538        return selectBitCast(I);
>> 1539
>> (gdb) call I->dump()
>>   %2 = call float @llvm.powi.f32(float %0, i32 %1)
>> (gdb)
>> (gdb) print *I
>> $12 = {<llvm::Value> = {
>>     _vptr$Value = 0x60c67f0 <vtable for llvm::CallInst+16>, VTy =
>> 0x61035c0,
>>     UseList = 0x61d3310, NameAndIsUsedByMD = {Value = 0}, SubclassID = 68
>> 'D',
>>     HasValueHandle = 0 '\000', SubclassOptionalData = 0 '\000',
>>     SubclassData = 0, NumOperands = 3, static MaximumAlignment =
>> 536870912},
>>   OperandList = 0x61b8e80}
>> (gdb)
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150130/3d0eb8f8/attachment.html>