search for: hashungoffus

I found the root cause, but I don't know what's the best approach to fix it. Under windows, 64 bit, when a function is created the void *User::operator new(size_t Size) operator allocates space + Use*. In the Use* the HasHungOffUses is set to true. So the ptr to the use* is returned as new object. This ptr is NOT the ptr that was allocated by the system. For that ptr you need ptr - word length. It's important that we use free on the original ptr. The void User::operator delete(void *Usr) deletes the use* when dtor is ca...

...inker <gekkekoe at gmail.com> wrote: > I found the root cause, but I don't know what's the best approach to fix > it. > > Under windows, 64 bit, when a function is created the void *User::operator > new(size_t Size) operator allocates space + Use*. > In the Use* the HasHungOffUses is set to true. So the ptr to the use* is > returned as new object. This ptr is NOT the ptr that was allocated by the > system. For that ptr you need ptr - word length. It's important that we use > free on the original ptr. > > The void User::operator delete(void *Usr) deletes...

I made the llvm::Function() constructor public (for testing purpose) and used the non-overloaded new. auto func = ::new llvm::Function(...) if (func) func->eraseFromParent(); And the heap corruption is gone! Did something changed in llvm::User::new between 3.7.1 and 3.8.0 ? I found a bug in llvm ? On Thu, Feb 25, 2016 at 12:10 PM, koffie drinker <gekkekoe at gmail.com> wrote: > I

I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a