Ok. I'm basically just following the model of the other fast-isel ports. 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 > <mailto: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 <mailto: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/e506ab25/attachment.html>
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>
It would be nice some day to revisit this idea of not using RTI or exceptions in
LLVM.
I think we overly complicate our lives with only a perceived, and not a real,
advantage .
________________________________
From: David Blaikie [dblaikie at gmail.com]
Sent: Friday, January 30, 2015 11:29 PM
To: Reed Kotler
Cc: LLVMdev at cs.uiuc.edu
Subject: Re: [LLVMdev] debug info for llvm::IntrinsicInst ???
On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at
mips.com<mailto: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<mailto: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<mailto: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/20150131/1d87bb16/attachment.html>