This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)




  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]