llvm dev - Apr 2017 - Identify virtual function call sites and candidate callees for it

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170426/7bc8afc4/attachment.html>

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/20170426/31e7b743/attachment.html>

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<mailto: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<mailto: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/49a1b762/attachment-0001.html>