[LLVMdev] [cfe-dev] Clang devirtualization proposal

[Hal Finkel]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Piotr Padlewski" <prazek at google.com>
> Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>, "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Thursday, July 23, 2015 4:21:42 PM
> Subject: Re: [cfe-dev] [LLVMdev] Clang devirtualization proposal
> 
> On Thu, Jul 23, 2015 at 11:42 AM, Piotr Padlewski < prazek at google.com
> > wrote:
> 
> 
> 
> HI,
> Yep, our proposal doesn't cover it, because this load ; icmp ;
> assume; will land global initilizer function, and main will not see
> it.
> At least if foo would be called multiple times, then we would only
> have one load from vtable, but unfortunatelly we will not be able to
> inline, or make direct call to it with this approach.
> I think that this case is rare enough to solve it right now.
> 
> 
> Piotr
> 
> 
> On Thu, Jul 23, 2015 at 10:30 AM, Geoff Berry < gberry at codeaurora.org
> > wrote:
> 
> 
> 
> 
> 
> 
> Hi Piotr,
> 
> 
> 
> You may be interested in a recent patch I posted:
> http://reviews.llvm.org/D11043
> 
> 
> 
> This patch addresses a de-virtualization case that I’m not sure would
> be handled by your current proposal, namely that of a virtual call
> where the ‘this’ object is a global variable.
> 
> For example:
> 
> 
> 
> struct A {
> 
> A();
> 
> virtual void foo();
> 
> };
> 
> void g(A * a) {
> 
> a->foo();
> 
> }
> 
> 
> 
> A a;
> 
> int main() {
> 
> g(&a);
> 
> 
> We could in principle emit the load/icmp/assume for a's vptr here,
> but I'm concerned that this is not actually sound in general.
> Consider:
> 
> 
> struct A;
> extern A a;
> void *p = &a; // emit load/icmp/assume here?
> struct A { virtual void f(); };
> A a;
> 
> 
> If we emit an assume on the vptr at the point where the address of a
> is taken, we get:
> 
> 
> @a = global %A zeroinitializer
> void @global_init() {
> load @a
> %x = icmp @a, @A.vtable
> call @llvm.assume(%x)
> store @a, @p
> call @A::A(@a)
> }
> 
> 
> ... where the assume call can be folded to "call @llvm.assume(i1
> false)", which (presumably) can be reduced further to "unreachable"

To confirm, yes, @llvm.assume(false) -> unreachable by llvm::removeUnreachableBlocks.

 -Hal

> (oops). (In Geoff's example, this is sound only because we're
> guaranteed that 'a' is initialized before we enter 'main', but an
> optimization that only fires for code within 'main' doesn't sound
> very useful.)
> 
> 
> We could support this with something weaker than the current
> load/icmp/assume pattern: we could imagine an instruction/intrinsic
> that says "any later load of pointer %p with !invariant.group !g
> will load the value %q", but that does not imply that the value %q
> is currently stored in %p. It's not clear to me whether that has
> sufficient value to be worthwhile.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> }
> 
> 
> 
> It might be worth considering if your approach could be extended to
> handle this case.
> 
> 
> 
> 
> --
> 
> Geoff Berry
> 
> Employee of Qualcomm Innovation Center, Inc.
> 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
> 
> 
> 
> From: llvmdev-bounces at cs.uiuc.edu [mailto:
> llvmdev-bounces at cs.uiuc.edu ] On Behalf Of Piotr Padlewski
> Sent: Wednesday, July 22, 2015 5:56 PM
> To: cfe-dev at cs.uiuc.edu Developers; llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Clang devirtualization proposal
> 
> 
> 
> 
> 
> Hi folks,
> 
> 
> this summer I will work with Richard Smith on clang devirtualization.
> Check out our proposal:
> 
> 
> 
> 
> https://docs.google.com/document/d/1f2SGa4TIPuBGm6y6YO768GrQsA8awNfGEJSBFukLhYA/edit?usp=sharing
> 
> 
> 
> 
> 
> And modified LangRef
> 
> 
> http://reviews.llvm.org/D11399
> 
> 
> 
> 
> 
> You can also check out previous disscussion that was started before
> our proposal was ready -
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-July/044052.html
> 
> 
> 
> 
> 
> Regards
> 
> 
> Piotr Padlewski
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory