search for: use_iterator_impl

...d be one i added > (IE "Dereferencing use iterator of x gives x") :) > > In the past 6 months, i did this twice by accident in passes and then > spent hours tracking it down. > > It actually makes me wonder whether use_iterator should even have an > operator * for the use_iterator_impl<Use> case. ISTM to basically > always be a bug (though this is an idle thought, i haven't thought > through the implications at all). > > > > On Tue, Jun 9, 2015 at 7:54 PM, Zack Waters <zswaters at gmail.com> wrote: > > Thanks Dan and Jon. I made an incorrec...

Thanks Dan and Jon. I made an incorrect assumption that the "use" iterator was actually giving me the "user" when de-referencing it. Did it always have this behavior in previous LLVM versions? I've seen lots of examples of the "use" iterator being dereferenced and resulting Instruction pointer being treated as the "user"? Thanks, Zack On Tue, Jun 9,

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