[ current-users@netbsd.org removed, tech-toolchain added]

warner losh writes:

>I've seen on other lists that haifa on mips helps a little bit too
>much and generates code that violates the MIPS ABI.  However, this is
>considered to be a bug in the ABI which binutils can easily work
>around.  I don't recall the specifics, but it was in the Linux/MIPS
>mailing list.  Might be something to look out for when you use th
>haifa enabled compile.  Specifically, it would generate multiple %hi
>references w/o a corresponding %lo and binutils didn't quite know how
>to deal with that.
>
>I'd be very interested to see what you come up with in this area.

i think i need some more info on the Linux problems...

I dug into this some more.  Looking at libbfd from binutils 2.8.1, the
problem is that the mips ELF ABI requires HI16 relocs to be emitted as
a pair with LO16 relocs, so that the linker can find the carry from
relocating the low-order 16 bits and add it into the relocation of hte
high-order 16 bits. Makes sense, really.

So when you expose the lui/li pair to egcs, and it schedules them
around another lui (say, from mips_move_1word), the carry gets added
in somwhere wrong. And even worse is scheduling two lui/li pairs such
that they overlap each each other:).  I dont think the MIPS ABI
requirement is a bug: theres no way to match up the carries from
interleaved lui/li pairs, unless you make some strong restrictions
about the registers involved, and _that_ breaks some optimizations
about array references. (see the comment above mips_check_split).

``la is your friend''. :)


So.  what I did was turn on -mdebuga. that tells
GO_IF_LEGITIMATE_ADDRESS to not accept the not-really-legal operands,
but it does _not_ enable the rtl patterns (define_insns) named "high"
and "low" in mips.md (since they depend on mips_split_addresses being
nonzero).

my change leaves mips_split_addresses off, so i _think_ it should be
be safe even with haifa.  the only iffy part is the lui in
mips_load_1word(). it would help a lot to get more info on what the
Linux/mips or other people have run into:
	   a) what, if anything,  they did about the egcs-1.1
	      botch with immediate offsets
	   b) exactly how much difference difference haifa makes
	   c) whether  they set mips_split_address, and how that
	      affects bugs, both withand without haifa.


with that info, i think we're getting close to a solid fix for this
that'll work with haifa, too.  And it'd be much much faster to ask
than, to do lots of `make builds' on a slowish mips, with the
different combinations, and wait for compiler crashes :)


[sorry for all the noise -- maybe it helps with problems egcs on other
 arches, but somehow i doubt it]