Subject: Re: EGCS enabled on mips
To: Warner Losh <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 10/31/1998 15:40:58
[ email@example.com 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
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]