PenYiWang via llvm-dev
2020-Jun-18 16:53 UTC
[llvm-dev] How to know the CallInst is a virtual call ?
Hi I know that a virtual call looks like this : %4 = load %class.base*, %class.base** %1, align 8 %5 = bitcast %class.base* %4 to void (%class.base*)*** %6 = load void (%class.base*)**, void (%class.base*)*** %5, align 8 %7 = getelementptr inbounds void (%class.base*)*, void (%class.base*)** %6, i64 0 %8 = load void (%class.base*)*, void (%class.base*)** %7, align 8 call void %8(%class.base* %4) There may be some action to get function pointer on vtable . But, when I scan a llvm ir file, if I just see a CallInst and it is an indirect call Is there any way to know whether the CallInst is a virtual call or not ? Thank you~ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/237dfe1d/attachment.html>
David Blaikie via llvm-dev
2020-Jun-18 17:25 UTC
[llvm-dev] How to know the CallInst is a virtual call ?
On Thu, Jun 18, 2020 at 9:53 AM PenYiWang via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi > > I know that a virtual call looks like this : > > %4 = load %class.base*, %class.base** %1, align 8 > %5 = bitcast %class.base* %4 to void (%class.base*)*** > %6 = load void (%class.base*)**, void (%class.base*)*** %5, align 8 > %7 = getelementptr inbounds void (%class.base*)*, void (%class.base*)** %6, i64 0 > %8 = load void (%class.base*)*, void (%class.base*)** %7, align 8 > call void %8(%class.base* %4) > > There may be some action to get function pointer on vtable . > > But, when I scan a llvm ir file, if I just see a CallInst and it is an indirect call > > Is there any way to know whether the CallInst is a virtual call or not ?Not exactly, no - LLVM has no concept of virtual calls specifically - they are "just" indirect calls through a vtable. LLVM optimizations generally shouldn't be trying to reconstruct more high level semantics than exist in LLVM IR - an optimization to improve virtual function calls (using the existing IR - not accounting for some special cases that might involve adding extra metadata, etc) should be framed in terms of indirect calls in general (perhaps indirect calls from functions in constant arrays - maybe that's the specific subcase you want to target, etc). - Dave
PenYiWang via llvm-dev
2020-Jun-18 17:52 UTC
[llvm-dev] How to know the CallInst is a virtual call ?
So if I want to know whether a CallInst is a C++ virtual call or not. I have to get the information at frontend/Clang. and then pass the information to middle-end/LLVM IR by myself. Is it right? Thank you David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午1:26寫道:> On Thu, Jun 18, 2020 at 9:53 AM PenYiWang via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > Hi > > > > I know that a virtual call looks like this : > > > > %4 = load %class.base*, %class.base** %1, align 8 > > %5 = bitcast %class.base* %4 to void (%class.base*)*** > > %6 = load void (%class.base*)**, void (%class.base*)*** %5, align 8 > > %7 = getelementptr inbounds void (%class.base*)*, void > (%class.base*)** %6, i64 0 > > %8 = load void (%class.base*)*, void (%class.base*)** %7, align 8 > > call void %8(%class.base* %4) > > > > There may be some action to get function pointer on vtable . > > > > But, when I scan a llvm ir file, if I just see a CallInst and it is an > indirect call > > > > Is there any way to know whether the CallInst is a virtual call or not ? > > Not exactly, no - LLVM has no concept of virtual calls specifically - > they are "just" indirect calls through a vtable. LLVM optimizations > generally shouldn't be trying to reconstruct more high level semantics > than exist in LLVM IR - an optimization to improve virtual function > calls (using the existing IR - not accounting for some special cases > that might involve adding extra metadata, etc) should be framed in > terms of indirect calls in general (perhaps indirect calls from > functions in constant arrays - maybe that's the specific subcase you > want to target, etc). > > - Dave >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200619/94a4a6eb/attachment.html>