search for: vtpr

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list

...means you're now saying that llvm.invariant.end ought to be >> left the way it is, right? > > I have no idea how to make use of llvm.invariant to help devirtualization. > If no use or other use case for them can be found, maybe they should be > removed. Apply invariant to the vtpr as long as the corresponding instance pointer is in use within a function. With an invariant vtpr (and better invariant support, and a front-end that uses it), devirtualization happens more or less automatically with -std-compile-opts. Do the same wherever an instance pointer is passed. Mark its...

...hat llvm.invariant.end ought to be >>> left the way it is, right? >> >> I have no idea how to make use of llvm.invariant to help devirtualization. >> If no use or other use case for them can be found, maybe they should be >> removed. > > Apply invariant to the vtpr as long as the corresponding instance > pointer is in use within a function. With an invariant vtpr (and > better invariant support, and a front-end that uses it), > devirtualization happens more or less automatically with > -std-compile-opts. That's not valid. Each function calle...

...t llvm.invariant.end ought to be >>> left the way it is, right? >> >> I have no idea how to make use of llvm.invariant to help devirtualization. >> If no use or other use case for them can be found, maybe they should be >> removed. > > Apply invariant to the vtpr as long as the corresponding instance > pointer is in use within a function. With an invariant vtpr (and > better invariant support, and a front-end that uses it), > devirtualization happens more or less automatically with > -std-compile-opts. Even if this works, it still requires us...

...t;>> left the way it is, right? >>> >>> I have no idea how to make use of llvm.invariant to help >>> devirtualization. >>> If no use or other use case for them can be found, maybe they should be >>> removed. >> >> Apply invariant to the vtpr as long as the corresponding instance >> pointer is in use within a function.  With an invariant vtpr (and >> better invariant support, and a front-end that uses it), >> devirtualization happens more or less automatically with >> -std-compile-opts. > > That's not v...

Kenneth Uildriks wrote: >> You're right, I hadn't thought this through. The whole point of making them >> local is to say that "I'm sure these callees won't modify that memory" >> regardless of what functions actually get called, even indirectly. We can't >> know that they won't modify the vptr in advance, so invariant doesn't work

> You're right, I hadn't thought this through. The whole point of making them > local is to say that "I'm sure these callees won't modify that memory" > regardless of what functions actually get called, even indirectly. We can't > know that they won't modify the vptr in advance, so invariant doesn't work > here. Making it non-local just means

...right? >>>> >>>> I have no idea how to make use of llvm.invariant to help >>>> devirtualization. >>>> If no use or other use case for them can be found, maybe they should be >>>> removed. >>> >>> Apply invariant to the vtpr as long as the corresponding instance >>> pointer is in use within a function. With an invariant vtpr (and >>> better invariant support, and a front-end that uses it), >>> devirtualization happens more or less automatically with >>> -std-compile-opts. >>...

...to be >>>> left the way it is, right? >>> >>> I have no idea how to make use of llvm.invariant to help devirtualization. >>> If no use or other use case for them can be found, maybe they should be >>> removed. >> >> Apply invariant to the vtpr as long as the corresponding instance >> pointer is in use within a function.  With an invariant vtpr (and >> better invariant support, and a front-end that uses it), >> devirtualization happens more or less automatically with >> -std-compile-opts. > > Even if this wor...