p2align inconsistencies

p2align inconsistencies

[N8TM]

I've noticed that p2align directives do not always get inserted at the top of
loops.  Taking as an example egcs-2.92.27/g77, with the g77 (first) version of
Livermore Fortran Kernel in ftp://members.aol.com/n8tm/lloops.shar.gz , there
is no .p2align at the head of the loop body for Kernel 6.  This makes no
difference today, as the position of the loop head exceeds the maximum padding
interval of 7 bytes from an even boundary, but this may explain why this loop
has given unexpectedly lower performance at times in the past.

With the options -O2 -malign-double -march=pentiumpro, g77 is transforming
Kernel 23 into a loop such as

go to 10
DO
	!swap registers
10	continue	! first time entry, compiler aligns this entry
	.....			!loop body
	IF(count==final)EXIT
END DO

and the .p2align is being applied to the first time entry point, so that there
is a padding gap right below the top of the loop on the repeated executions,
and the loop requires an extra cache line.  I couldn't measure any significant
performance difference according to whether this loop was aligned to eliminate
the padding gap or the extra cache line, so maybe there's nothing in this, and
g77 is doing fairly well on these loops.

BTW, I've wondered whether it's safe to ignore the problems which gcc has had
for several snapshots with combinations of -Os and -O2 with -march=pentiumpro
or hppa1.1, which haven't been seen to cause problems in g77 as long as the
compiler and/or libraries are built without these combinations.

Re: p2align inconsistencies

[Jeffrey A Law]

  In message < a321f224.3672df68@aol.com >you write:
  > I've noticed that p2align directives do not always get inserted at the top 
  > of loops.
Most likely because gcc does not use natural loop analysis, but instead uses
the source to identify loops.

Loops constructed with gotos will probably not be marked by the front end
as loops and thus we probably won't emit alignment directives at the entry
to such loops.

In a similar manner, we will not perform loop optimizations on loops created
by a bunch of gotos.

jeff