On Sat, Nov 16, 2013 at 11:37:36AM +0100, Richard Biener wrote: > "Ondřej Bílka" <nel...@seznam.cz> wrote: > >On Fri, Nov 15, 2013 at 09:17:14AM -0800, Hendrik Greving wrote: > > IIRC what can still be seen is store-buffer related slowdowns when you have a > big unaligned store load in your loop. Thus aligning stores still pays back > last time I measured this.
Then send you benchmark. What I did is a loop that stores 512 bytes. Unaligned stores there are faster than aligned ones, so tell me when aligning stores pays itself. Note that in filling store buffer you must take into account extra stores to make loop aligned. Also what do you do with loops that contain no store? If I modify test to int set(int *p, int *q){ int i; int sum = 0; for (i=0; i < 128; i++) sum += 42 * p[i]; return sum; } then it still does aligning. There may be a threshold after which aligning buffer makes sense then you need to show that loop spend most of time on sizes after that treshold. Also do you have data how common store-buffer slowdowns are? Without knowing that you risk that you make few loops faster at expense of majority which could likely slow whole application down. It would not supprise me as these loops can be ran mostly on L1 cache data (which is around same level as assuming that increased code size fits into instruction cache.) Actually these questions could be answered by a test, first compile SPEC2006 with vanilla gcc -O3 and then with gcc that contains patch to use unaligned loads. Then results will tell if peeling is also good in practice or not.