[LLVMbugs] [Bug 13940] New: IR extension to denote language guarantee that two loads may load same value, even in presence of visible changes in between

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=13940

             Bug #: 13940
           Summary: IR extension to denote language guarantee that two
                    loads may load same value, even in presence of visible
                    changes in between
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In this code:

 Cls *p = new Cls;
 p->virtual_method1();
 p->method_changing_vptr();  // uses placement new to legally change the vptr
 p->virtual_method2();  // invalid!
 Cls *q = p;
 q->virtual_method2();  // this must get a new vptr lookup.

there is no need to reload p's vptr, even if the method did update the vptr.

C++ [basic.life] gives us a guarantee that a pointer will only update to point
to a new object allocated at the same place in memory under certain
circumstances. If the C++ code uses the same pointer, reference or name to
refer to the object, then we can prove that the vptr and any const members did
not change.

I'd like clang to compute whether a load is eligible for this treatment per the
rules in C++, and encode that in LLVM IR for further optimization. (Note that
this is different from @llvm.invariant because
method_changing_vptr_through_placement_new may be inlined and needs to see the
new vptr for correctness.)

In LLVM, a new intrinsic:

 declare {}* @llvm.load.group()

and new metadata on loads:

 !load.group %group

where %group must be the result of a call to llvm.load.group. Any two loads
with the same %group value are known to produce the same value. That alone
should be enough to cover many cases of devirtualization (and reference members
and const members and various other fun things).

For clang, let us say that two expressions E1 and E2 of the same type denote
the same value if:

 * E1 and E2 both name the same variable, which is either of class or
reference-to-class type or const pointer-to-class type, or is of non-const
pointer type and is known to have not changed between the evaluations of E1 and
E2. (By introductory text in [basic.life]).
 * E1 and E2 are of the form E3.x and E4.x, or E3->x and E4->x, or E3[x] and
E4[x], for the same x, and E3 and E4 denote the same value, and the denoted
subobject either has a const-qualified type or is a reference. (By bullet 3,
ibid).
 * (Fudging a bit on E1 and E2 being expressions...) E1 and E2 are both
references to the same vptr slot. (By bullet 2 or 4, ibid).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.