search for: vptrs

...on't know enough > optimizer details to construct a better one. > > Can you get by with a MayAlias?  It seems like you can divirtualize > everything that MustAlias and ignore the rest. I see what you mean. If the placement new result mayalias its original pointer, we can hold both vptrs invariant and have everything else reloaded from memory as appropriate. Now if the placement-new is known to place an object of a different type from the original object, the front-end can NoAlias them instead because pointers to the old object become invalid according to the standard and any use...

...optimizer details to construct a better one. >> >> Can you get by with a MayAlias?  It seems like you can divirtualize >> everything that MustAlias and ignore the rest. > > I see what you mean.  If the placement new result mayalias its > original pointer, we can hold both vptrs invariant and have everything > else reloaded from memory as appropriate.  Now if the placement-new is > known to place an object of a different type from the original object, > the front-end can NoAlias them instead because pointers to the old > object become invalid according to the s...

On Sun, Nov 14, 2010 at 11:17 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > To fix that and compile C++ correctly while aggressively > devirtualizing it, we would need to apply "noalias" to the result of > placement-new in all cases, even when placement-new is inlined.  More > generally, when inlining any function with a "noalias" return, the >

Right now, I don't see any way to declare that a pointer value within a function does not alias any pointer not based on it. Basically, I would like to be able to apply "noalias" to an instruction/virtual reg the same way that noalias is applied to function arguments. A few weeks ago when discussing devirtualization possibilities in C++, it turned out that while you can assume that

...) { return &m; } }; struct B : A { virtual void foo() { printf("%s\n", __PRETTY_FUNCTION__); } }; int main(void) { A *ap = new A; ap->foo(); int *const apz = ap->zip(); B *bp = new (ap) B; if (apz == bp->zip()) { bp->foo(); } } Here we don't compare vptrs, but pointers with small offset like: a+4 == b+4 And because we can transform it to a == b, it breaks. I started thinking about handling it in the LLVM instead, and my first idea was as folows: Because the invariant.group is associated with the pointer value, preserving the invariant.group in...

Hi Hal, Hal Finkel via llvm-dev wrote: > Some questions: Do we allow stores to these locations at all? Only if I'd vote for disallowing stores to these locations, but if "stores allowed only if the value is the same" is helpful in some situation then I don't have specific reasons why that would be problematic. > the value is the same? Must any change be observable to

...s in the callee. The reason I’m >> starting with SCCP is that it already deals with keeping track of computing >> when all of a function’s possible call sites are known, as well as merging >> values in a lattice. >> > Given that we use !invariant.group loads when loading vptrs, what > additional value do you think you can get from this? An example of a case > where you could do better than the current approach of > -fstrict-vtable-pointers with this technique would help a lot in > understanding this. > >> 2. clang: Emitting llvm.assume vtable l...

Hi All, I have a two-part de-virtualization enhancement that I'm considering working on and am looking for any feedback on how feasible it is. The two parts are: 1. llvm: Extending inter-procedural SCCP (or some other IPO module pass) to propagate llvm.assume's across function calls. The basic idea would be to collect the set of assumptions for each argument at each call

...st sizeof(User*) bits of a User instance. Hi Stefanus! Your analysis is perfectly correct. I Was AFK for the last two days, so I couldn't tell you this same story. The algorithm relies on the fact that the LSBit of the first "pointer" in User is zero. This is normally the case with VPtrs, which are "normally" placed there by ABIs. Originally, I just checked that bit verbatim, and later by means of PointerIntPair. The problem arose when PointerIntPair's layout changed. I think we could switch back without a loss. Btw. the alignment of pointers in a 32 bit machine is 4...

...ly if the value is the same" is helpful in some situation then I don't have specific reasons why that would be problematic. I disagree. It's much easier to write fronted and use invariant load when you can emit stores that store the same value. For example with invariant.group used on vptrs optimizer can assume the 2 loads load the same vtable, even when you can write code in c++ that is valid that store vptr after calling virtual function (like placement new(this) with the same type). > the value is the same? Must any change be observable to be a problem? Do Not sure what you m...

...is is perfectly correct. I Was AFK for the last two days, > so I couldn't > tell you this same story. Thanks, glad I was on the right track :). > The algorithm relies on the fact that the LSBit of the first "pointer" > in User > is zero. This is normally the case with VPtrs, which are "normally" > placed there > by ABIs. Originally, I just checked that bit verbatim, and later by > means of > PointerIntPair. The problem arose when PointerIntPair's layout > changed. > I think we could switch back without a loss. > > Btw. the alignme...

On 1-May-09, at 8:35 PM, Chris Lattner wrote: > I still don't understand why this is a problem, but I decreased the > default to 2 bits. Please verify that this helps, I think I've figured out what's going on, and why no assertions are caused by this. It doesn't necessarily have anything to do with User* pointer alignment per se (although I believe that could still

On May 1, 2009, at 3:40 PM, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with