On Wed, Oct 26, 2016 at 11:28 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Tue, Oct 25, 2016 at 4:31 PM, Martin Liška <mli...@suse.cz> wrote: >> On 10/24/2016 03:51 PM, Richard Biener wrote: >> >>> It's quite ad-hoc :/ The IFN will also be a memory optimization >>> barrier unless you add special support >>> for it in the alias oracle - so the performance measurement needs to >>> be taken with a grain of salt >>> (same is true for all atomics of course... - I have some local patches >>> to improve things here). >> >> Good, thus please ping me with the patches you have and I'll integrate it.
This is what I have in my tree (appearantly only points-to changes, I suppose general alias changes will be controversical as the builtins would lose their "compiler memory barrier" behavior). Richard. >>> >>> The way you implement process_sm_for_coverage_counter is more like a >>> final value replacement. >>> You could maybe use create_iv for the loop counter or even wind up >>> computing the final value >>> (number of iterations) only after the loop, avoiding the IV completely >>> (eventually SCEV cprop >>> saves you here afterwards). >> >> Or maybe we can basically assign loop->niter as the argument of >> UPDATE_COVERAGE_COUNTER >> function? > > Yes, that's what I said. > > Richard. > >> Martin >> >>> >>> Richard. >>
p
Description: Binary data
