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>
David Blaikie via llvm-dev
2020-Jun-18 18:15 UTC
[llvm-dev] How to know the CallInst is a virtual call ?
On Thu, Jun 18, 2020 at 10:52 AM PenYiWang <s89162504 at gmail.com> wrote:> > 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?Yes... but you maybe shouldn't be? What do you plan to do with that information? (not that there aren't/haven't been efforts to improve virtual call performance - I think there's something using ThinLTO to do a whole program analysis of virtual calls you could look into as examples of optimizations on virtual function calls)> > 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
PenYiWang via llvm-dev
2020-Jun-18 18:35 UTC
[llvm-dev] How to know the CallInst is a virtual call ?
I read some paper from NDSS and USENIX Security about protecting C++ virtual calls. So now I know maybe these paper implementation must modify front-end/Clang. David Blaikie <dblaikie at gmail.com> 於 2020年6月19日 週五 上午2:16寫道：> On Thu, Jun 18, 2020 at 10:52 AM PenYiWang <s89162504 at gmail.com> wrote: > > > > 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? > > Yes... but you maybe shouldn't be? What do you plan to do with that > information? > > (not that there aren't/haven't been efforts to improve virtual call > performance - I think there's something using ThinLTO to do a whole > program analysis of virtual calls you could look into as examples of > optimizations on virtual function calls) > > > > > 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/5271a5d9/attachment.html>