This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)
- To: Mark Klein <mklein at dis dot com>
- Subject: Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Sun, 29 Aug 1999 04:08:51 -0600
- cc: gcc at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <4.1.19990827171727.00c5a960@garfield.dis.com>you write:
> OK. I'll keep tracking what you've got (thank heaven I ported CVS to MPE).
> Let me know when you want me to repost them and I'll do so.
One possibility would be to try to deal with it in smaller hunks rather than
all at once. We can start with stuff that is non-controversial then deal
with progressively more issues.
That way we can work to reduce the amount of patches you have to carry around
and we don't have to do a "mega patch" (which have the tendency to break
things).
So let's start with just your new config files and configure.in fragment
first. Can you send just those pieces?
> For sake of argument, here's mine. I reformatted it a bit to understand it
> better. The only real changes are to handle the long double:
A few notes....
>
> struct rtx_def *
> function_arg(cum, mode, type, named)
> const CUMULATIVE_ARGS *cum;
> enum machine_mode mode;
> tree type;
> int named;
We always indent function arguments 5 spaces. Not 2, not 4, not a tab, but
5 spaces (hell if I know why the GNU standards mandate 5 spaces).
> /*
> * See if there is at least one argument register still available.
> */
We write comments like
/* blah blah
foo bar com. */
> if (4 >= cum->words + FUNCTION_ARG_SIZE (mode, type))
> {
>
> if (!TARGET_PORTABLE_RUNTIME ||
> type == 0 ||
> !FLOAT_MODE_P (mode) ||
> TARGET_SOFT_FLOAT ||
> cum->nargs_prototype > 0)
We write conditionals like
if (cond1
|| cond2
|| cond3)
> {
> if (FUNCTION_ARG_SIZE (mode, type) > 2)
We always indent two spaces after an open-curley.
As for the actual code, I suspect it's similar to the stuff we're playing with
internally, but simpler :-) The PA64 calling conventions are similar, but
not quite the same as the portable runtime. Ugh.
It certainly is a hell of a lot easier to follow the code once it's broken out
into a function :-) Probably the next one to break into a function on the PA
will be GO_IF_LEGITIMATE_ADDRESS. The whole idea that we have macros that
take up a page is absurd. Nobody should write code like that :-)
jeff