i386 code label alignment patch

[Jeffrey A Law]

  In message < 199805072149.RAA02606@jwlab.FEITH.COM >you write:
  > > 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?
Often, but we can not depend on it.

  > 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.
Ha!  Nothing's ever easy with canadian cross builds :-)

Let's say I want to build a Cygwin hosted toolchain that generates
code for the Hitachi H8 processor.  Let's also assume that I don't
actually have a Cygwin machine I can build stuff on.  So I'm going
to build things on my hpux box.

First I would build and install an hpux-x-cygwin toolchain.  This is
a standard cross build.

Second I would build and install an hpux-x-h8 toolchain.  Again a
standard cross build.

Now for the tricky part, I have to use the hpux-x-cygwin to build
an assembler, compiler, etc which will run on a cygwin host and
generate h8 code (cygwin-x-h8).

In this case the assembler that gets built in the object tree is a
cygwin binary and is not executable by the hpux box.  Similarly for
the gcc, gdb, etc that get built.  And thus to build target libraries
like libgcc the build procedure uses the hpux-x-h8 tools that were
built earlier in the process.



  >   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 necessar y
  >      since these platforms currently use a slightly busted gas.
OK.  And we know that those platforms use gas and only gas right
(even if it's an old, busted version -- so long as our configure
stuff identifies it as some version of gas and provides an appropriate
definition of the ALIGN macros.

We *might* want to provide versions of the ALIGN macros for the case
when no version of gas was found -- I'm really unsure if we should
depend on the *bsd* flavors always using 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.
Right.   Hmmmm.  How exactly does the configure script determine
what version of gas is going to be built in the build tree?  Remember
at configure time in a single tree build gas is not yet built.

  >   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.
I think that the interpretation of the argument to .align is/was
target dependent.

  > 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 think the gas.h code will do the right thing if we properly
detect gas-1.xx.

  > 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).
Ah.  I think it might be better to keep both the desired alignment
and the maximum "hole size" allowed together in final.c's tables.
It just seems like a cleaner way to approach the problem.

We'd probably want a single new macro for emitting these new kind
of alignment directives.  Similarly for a mechanism for the target
to provide these extra values.

That way we don't have to change all the targets to use a new
interface.

  > 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.
Yea.  Thinking more about that, that would always be safe.  Someday
it might be interesting to improve shorten_branches to handle this
better, but that can wait until we have a target which uses
shorten_branches *and* defines these new kind of alignment values.

jeff