Page MenuHomePhabricator

Const fold vtable load from global variable
AbandonedPublic

Authored by gberry on Jul 8 2015, 2:04 PM.

Details

Summary
Take advantage of the TBAA "vtable access" annotation on loads of a
global variable's vtable.  This annotation marks loads as being loads of
a C++ object's vtable pointer.  Since we know that a vtable pointer
cannot be changed to a different value after object construction, if we
see a global object with an initializer that has a non-null vtable
pointer, we can replace vtable loads from that object with the global
initializer's vtable value.

Diff Detail

Event Timeline

gberry updated this revision to Diff 29284.Jul 8 2015, 2:04 PM
gberry retitled this revision from to Const fold vtable load from global variable.
gberry updated this object.
gberry added a subscriber: llvm-commits.
gberry added a comment.Jul 8 2015, 2:35 PM

Touching to get email send to llvm-commits

mcrosier edited reviewers, added: hfinkel, chandlerc, dblaikie, arsenm; removed: mcrosier.Jul 8 2015, 2:43 PM
mcrosier set the repository for this revision to rL LLVM.
mcrosier added a subscriber: mcrosier.
reames added a subscriber: reames.Jul 8 2015, 10:53 PM

General comment: Having a special case in TBAA for a constant after initialization value seems like the wrong factoring here. Supporting a more general extensions of !invariant.load would seem to be more generally useful.

Having said that, it doesn't look like you're adding the mechanism, just extending it. As such, my comment isn't directly relevant to the patch at hand.

Ping?

FWIW, this change improves spec2006/astar by 6% on AArch64 a57

rnk added a subscriber: rnk.Jul 23 2015, 11:22 AM

@majnemer and I agree that this is incorrect. It ignores how the vtable changes over time during object construction.

Reid,

Thanks for your feedback. Just to be clear, your objection is that there may be subsequent writes to @gS's vtable pointer during construction such that the value folded into @gS's initializer (i.e. the first vtable value written) is different from the value that would be loaded at the call site?

rnk added a comment.Jul 23 2015, 1:46 PM

Reid,

Thanks for your feedback. Just to be clear, your objection is that there may be subsequent writes to @gS's vtable pointer during construction such that the value folded into @gS's initializer (i.e. the first vtable value written) is different from the value that would be loaded at the call site?

Exactly. Right now it seems like you're looking for "does the relevant field of this global have a non-zero value". For now, this coincidentally does the trick, but there's no real guarantee that it will always work.

gberry abandoned this revision.Jul 24 2015, 10:49 AM