Re: i386 code label alignment patch

[john at feith dot com (John Wehle)]

> I don't think you can use an autoconf test like that -- what happens
> for a cross or canadian cross build?  It doesn't look like you handle
> those cases.  Then again, I'm not an autoconf guru, so I could be
> missing something simple.

When doing a cross build isn't gas in the build tree?  Configure already
looks for it and creates a symbolic link if it is in the build tree.  The
autoconf test checks for gas in the gcc directory first before using
the one in the path.  I was kind of hoping that a canadian cross build
was more or less just doing a cross build followed by another cross build
in which case it should be the same issue as a regular cross build.

> Maybe the way to go is make worst case assumptions in those cases.
> Thoughts?

Thought I did :-).  Possible situations:

  1) Configure doesn't find gas which means that i386/gas.h doesn't
     redefine ASM_OUTPUT_ALIGN or define ASM_OUTPUT_LABEL_ALIGN_AFTER_BARRIER
     or ASM_OUTPUT_LOOP_ALIGN.  This should result in the original
     behavior as before my patch.

     This should only cause a problem when building for 386bsd, freebsd,
     and netbsd since as a minor cleanup I removed ASM_OUTPUT_ALIGN from
     their header files and depend on i386/gas.h to redefine it if necessary
     since these platforms currently use a slightly busted gas.

  2) Configure finds a version of gas which is newer than that being
     used by the target.  This will cause problems since egcs will
     produce assembler code which uses features not present in the
     assembler used by the target.

  3) Configure finds a version of gas which is older than that being
     used by the target.  In general this shouldn't cause a problem
     since it just means certain gas features will not be used.

     The one place where this could be an issue is if there are versions
     of gas less than 2.0 where the argument to align is in bytes.  I
     made the assumption that the older versions always use LOG.

The possible problems associated with situations 1 and 3 can be eliminated
by simply not having i386/gas.h redefine ASM_OUTPUT_ALIGN if the detected
version of gas is less than 2.0 and by not modifying the 386bsd, freebsd,
and netbsd header files.  I'm not sure when situation 2 would normally
happen.  I'm certainly open to ideas on how to better implement this.

> I also don't see why we need new output routines for
> ASM_OUTPUT_LABEL_ALIGN_AFTER_BARRIER.  Isn't the desired alignment
> for each label stored in LABEL_TO_ALIGNMENT?  Can you say more about
> the motivation behind this aspect of the change

The desired alignment is stored in LABEL_TO_ALIGNMENT.  However,
the Intel recommendation for loop entry and labels after barriers
is to align on a 16 byte boundary if it is less than 8 bytes
away.  The ASM_OUTPUT_LABEL_ALIGN_AFTER_BARRIER and
ASM_OUTPUT_LOOP_ALIGN macros accomplish this by using p2align
with desire alignment from LABEL_TO_ALIGNMENT as the first
argument and 7 as the third argument.  This is a feature of
gas 2.8 (and later).

> I also worry about the correctness of shorten_branches in the case
> where the label is far away from the jump site and thus the alignment
> directive has no effect.  This may cause problems since shorten_branches
> no longer uses trivial algorithms that either only grow or only shrink.

My impression from the comments in final.c is that aligning on a smaller
boundary than recorded in LABEL_TO_ALIGNMENT is okay since shorten_branches
is based on the worst case scenario.  I wouldn't mind someone familiar with
shorten_branches double checking my logic.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------