[llvm-dev] Identify virtual function call sites and candidate callees for it

[Peter Collingbourne via llvm-dev]

Hi Anahit,

Instead of passing -fsanitize=cfi try passing -fwhole-program-vtables. That
should make the frontend emit the assume intrinsics.

Peter


On Apr 27, 2017 8:12 AM, "Hayrapetyan, Anahit" <anahit.hayrapetyan at tum.de>
wrote:

Hi Peter,

Thanks a lot for the response. After looking at WholeProgramDevirt pass
sources and particularly the functions you mentioned, I’m clear how to use
llvm type checking intrinsics to solve my problems.

But when I tried to run the wholeprogramdevirt pass for a sample program,
I’m not getting the expected results.

Consider the example from my first email, with slight changes, that is: not
overriding virtual F in derived class.

class B {

virtual void F() { // do something }

};

class D : public B {};

B* d = new D();

d->F();

>From the comments in WholeProgramDevirt class I understand that the “single
implementation devirtualization” should be applied to this example and the
indirect call of F should be replaced with the direct call to B::F. However
when I run the pass, the indirect call is still there. The reason why no
transformation is taking place is that DevirtModule::run function along
with type test intrinsic tries to also find llvm assume intrinsic, before
starting the transformation. But there is no assume intrinsic.


Do I need to run some other passes to get llvm.assume intrinsic generated?


As for now, I’m getting bytecode with:

clang++ -fvisibility=hidden -flto -fsanitize=cfi -c -emit-llvm simple.cpp
-o simple.bc

opt -wholeprogramdevirt simple.bc -o simple_devirt.bc


I'm using llvm 3.9.0.


Thanks,

Anahit.


------------------------------
*From:* Peter Collingbourne <peter at pcc.me.uk>
*Sent:* Wednesday, April 26, 2017 7:01 PM
*To:* Hayrapetyan, Anahit
*Cc:* llvm-dev at lists.llvm.org
*Subject:* Re: [llvm-dev] Identify virtual function call sites and
candidate callees for it

Hi Anahit,

You may find it useful to take a look at the WholeProgramDevirt pass, it
uses the type metadata that was introduced for CFI to identify virtual call
sites and candidate callees for devirtualization. See in particular
the scanTypeTestUsers and tryFindVirtualCallTargets functions.

Peter

On Wed, Apr 26, 2017 at 9:44 AM, Hayrapetyan, Anahit via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> I have an analysis pass which collects information about functions based
> on their call sites. There are problems I’m facing with processing virtual
> function calls, namely
>
> . How identify virtual call sites in my pass?
>
> . How Identify candidate callees for the given virtual call site?
>
> For the following example, the information I want to get would be identify
> call of  F and as a possible callees have both B::F and D::F.
>
> class B {
>
> virtual void F() { // do something }
>
> };
>
> class D : public B {
>
> void F() { // do something else }
>
> };
>
> B* d = new D();
>
> d->F();
>
> While doing some investigation on my problem, I found about CFI and how it
> makes use of llvm type.test intrinsic to check validity of virtual table
> pointers. I thought it might be useful. But still am not sure if this would
> be the correct way to solve the problem and even if it is how extend this
> approach to get information about potential callees.
>
> I would greatly appreciate any ideas or hints on how to solve these
> problems.
>
> Anahit.
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


-- 
--
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170427/2a46de50/attachment.html>