Hi, On Fri, 12 Aug 2016, Denys Vlasenko wrote:
> > Have you tested the performance impact of your patch? Note that the > > macro you changed is used for function and code label alignment. So, > > unless I misunderstand something that means that if the large > > alignment can't be achieved for e.g. a loop start label, you won't > > align it at all anymore. This should be fairly catastrophic for any > > loopy benchmark, so anything like this would have to be checked on a > > couple benchmarks from cpu2000 (possibly cpu2006), which has some that > > are extremely alignment sensitive. > > > > Even for function labels I'd find no alignment at all strange, and I > > don't see why you'd want this. > > For many generations now, x86 CPUs have at least 32, and usually 64 byte > cachelines. Decoders fetch instructions in blocks of 32 or 64 bytes. Not > less. Instructions which are "misaligned" (for example, starting at byte > 5) within a cacheline but still fitting into one cacheline are fetched > in one go, with no penalty. Yes, I know all that. Fetching is one thing. Loop cache is for instance another (more important) thing. Not aligning the loop head increases chance of the whole loop being split over more cache lines than necessary. Jump predictors also don't necessarily decode/remember the whole instruction address. And so on. > Aligning to 8 bytes within a cacheline does not speed things up. It > simply wastes bytes without speeding up anything. It's not that easy, which is why I have asked if you have _measured_ the correctness of your theory of it not mattering? All the alignment adjustments in GCC were included after measurements. In particular the align-by-8-always (for loop heads) was included after some large regressions on cpu2000, in 2007 (core2 duo at that time). So, I'm never much thrilled about listing reasons for why performance can't possibly be affected, especially when we know that it once _was_ affected, when there's an easy way to show that it's not affected. Ciao, Michael.
