[LLVMdev] [cfe-dev] Clang devirtualization proposal (original) (raw)

Hal Finkel hfinkel at anl.gov
Sat Jul 25 12:30:47 PDT 2015

----- 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 @globalinit() { 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

More information about the llvm-dev mailing list