On Fri, 2021-09-10 at 09:33 -0400, Peter Xu wrote: > On Fri, Sep 10, 2021 at 02:19:40PM +0200, nsaenzju@xxxxxxxxxx wrote: > > > I also don't understand why you explicitly removed the compiler barrier. IIUC > > > when without it the compiler could move these instructions to be before/after > > > other instructions generated in the c code. That may not really happen in > > > practise, but just curious why the explicit removal. > > > > I removed it too as I see no justification for it. There is nothing, except for > > the actual timestamp values (which are safe as they come from an mrs), that > > could suffer from the compiler prefetching the value, or reordering accesses. > > I'll add a comment on the commit message. > > Again I have no solid example, but wondering whether when without compiler > barrier the compiler would be legal to compile this code clip: > > t1 = frc(); > a = 1; > t2 = frc(); > > into something like: > > t1 = frc(); > t2 = frc(); > a = 1; > > It's just that iiuc compiler barrier has 0 overhead to us. No strong opinion > anyways. My understanding is that can only happen when the expression to right of 'a' has no dependencies with t2. And at that stage, do we really care? Well, yes, for example if you're measuring how long it took to assign a, which is similar to what we do: workload_fn workload = g.workload->w_fn; frc(&t1) workload() frc(&t2) But in that case the compiler is forced to handle the indirect function call and IIUC there is little optimization todo, so we're safe without barriers. That said, I don't feel overly confident about all this, and there is little downside to the compiler barriers, so I'll just add them. -- Nicolás Sáenz
