HARD_REGNO_MODE_OK on PA-RISC (revisited)

HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

A while back we had a discussion about how I feel HARD_REGNO_MODE_OK is wrong.
We never resolved it back then, so I'd like to try again.

Facts:

PA1.0
32 general registers, each 32 bits.
16 floating pointer registers, each 64 bits. 32 bit FP values can only be
in the
left half of a 64 bit FP register. Registers are numbered 0..15.
128 bit FP must be aligned on an even register boundary.

PA1.1
32 general registers, each 32 bits.
32 floating point registers, each 64 bits. Each half of the register may
contain
and operate on 32 bit FP values. Registers are numbered 0..31. Left and right
half are indicated by appending an "L" or "R" to the register name (e.g.
%fr4L).
128 bit FP must be aligned on an even register boundary.

A general register may hold any reg/subreg of 32 bits in any alignment.

Here's the current HARD_REGNO_MODE_OK:

/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
   On the HP-PA, the cpu registers can hold any mode.  We 
   force this to be an even register is it cannot hold the full mode.  */ 
#define HARD_REGNO_MODE_OK(REGNO, MODE) \ 
  ((REGNO) == 0 ? (MODE) == CCmode || (MODE) == CCFPmode                \
   /* On 1.0 machines, don't allow wide non-fp modes in fp regs. */     \
   : !TARGET_PA11 && FP_REGNO_P (REGNO)                         \
     ? GET_MODE_SIZE (MODE) <= 4 || GET_MODE_CLASS (MODE) == MODE_FLOAT \
   /* Make wide modes be in aligned registers. */                       \
   : GET_MODE_SIZE (MODE) <= 4 || ((REGNO) & 1) == 0)

(Please note that the register mapping for gcc FP is such that the even
registers
are the left half of the FP register. So, pseudo register 32 is hardware
register
%fr4. Pseudo register 33 is hardware register %fr4R, 34 is %fr5 and 35 is
%fr5R,
etc.)

I believe the macro is wrong because it forces even register alignment for
larger
modes in the general register file as well as the FP registers. Calling
conventions do provide for certain register alignment in the general register
file, but only in the argument registers, and that's handled by another macro.

In addition, it will need to change for long double support that in TFMODE,
the FP pseudo registers must be evenly divisible by 4.

Here's what I propose:

/*
 * Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
 * 32 bit reg/subreg can fit in any general register. On PA1.0, FP regs
 * are 64 bits wide, but 32 bit quantities must be in the leftmost 32
 * bits of the FP register. On PA1.1, FP regs are still 64 bits wide,
 * but both halves can contain 32 bit quantities. In gcc, these registers
 * are each treated as a separate 32 bit FP register. Modes greater
 * than 32 bits must be aligned on even registers. 128 bit floating
 * point must be aligned in evenly aligned FP registers on PA 1.0 and
 * because of the remapping for PA1.1, registers evenly divisible by 4.
 * For PA 1.0, disallow wide non-floating point modes in FP registers.
 */
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
  ((REGNO) == 0                                                         \
    ? (MODE) == CCmode || (MODE) == CCFPmode                            \
    : FP_REGNO_P (REGNO)                                                \
       ? !TARGET_PA11                                                   \
          ? GET_MODE_SIZE (MODE) <= 4 ||                                \
            GET_MODE_CLASS (MODE) == MODE_FLOAT &&                      \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0 ||         \ 
            ((REGNO) & 3) == 0)                                         \
          : GET_MODE_SIZE (MODE) <= 4  ||                               \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0) ||        \
            ((REGNO) & 3) == 0                                          \
       : 1)
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

A while back we had a discussion about how I feel HARD_REGNO_MODE_OK is wrong.
We never resolved it back then, so I'd like to try again.

Facts:

PA1.0
32 general registers, each 32 bits.
16 floating pointer registers, each 64 bits. 32 bit FP values can only be
in the
left half of a 64 bit FP register. Registers are numbered 0..15.
128 bit FP must be aligned on an even register boundary.

PA1.1
32 general registers, each 32 bits.
32 floating point registers, each 64 bits. Each half of the register may
contain
and operate on 32 bit FP values. Registers are numbered 0..31. Left and right
half are indicated by appending an "L" or "R" to the register name (e.g.
%fr4L).
128 bit FP must be aligned on an even register boundary.

A general register may hold any reg/subreg of 32 bits in any alignment.

Here's the current HARD_REGNO_MODE_OK:

/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
   On the HP-PA, the cpu registers can hold any mode.  We 
   force this to be an even register is it cannot hold the full mode.  */ 
#define HARD_REGNO_MODE_OK(REGNO, MODE) \ 
  ((REGNO) == 0 ? (MODE) == CCmode || (MODE) == CCFPmode                \
   /* On 1.0 machines, don't allow wide non-fp modes in fp regs. */     \
   : !TARGET_PA11 && FP_REGNO_P (REGNO)                         \
     ? GET_MODE_SIZE (MODE) <= 4 || GET_MODE_CLASS (MODE) == MODE_FLOAT \
   /* Make wide modes be in aligned registers. */                       \
   : GET_MODE_SIZE (MODE) <= 4 || ((REGNO) & 1) == 0)

(Please note that the register mapping for gcc FP is such that the even
registers
are the left half of the FP register. So, pseudo register 32 is hardware
register
%fr4. Pseudo register 33 is hardware register %fr4R, 34 is %fr5 and 35 is
%fr5R,
etc.)

I believe the macro is wrong because it forces even register alignment for
larger
modes in the general register file as well as the FP registers. Calling
conventions do provide for certain register alignment in the general register
file, but only in the argument registers, and that's handled by another macro.

In addition, it will need to change for long double support that in TFMODE,
the FP pseudo registers must be evenly divisible by 4.

Here's what I propose:

/*
 * Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
 * 32 bit reg/subreg can fit in any general register. On PA1.0, FP regs
 * are 64 bits wide, but 32 bit quantities must be in the leftmost 32
 * bits of the FP register. On PA1.1, FP regs are still 64 bits wide,
 * but both halves can contain 32 bit quantities. In gcc, these registers
 * are each treated as a separate 32 bit FP register. Modes greater
 * than 32 bits must be aligned on even registers. 128 bit floating
 * point must be aligned in evenly aligned FP registers on PA 1.0 and
 * because of the remapping for PA1.1, registers evenly divisible by 4.
 * For PA 1.0, disallow wide non-floating point modes in FP registers.
 */
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
  ((REGNO) == 0                                                         \
    ? (MODE) == CCmode || (MODE) == CCFPmode                            \
    : FP_REGNO_P (REGNO)                                                \
       ? !TARGET_PA11                                                   \
          ? GET_MODE_SIZE (MODE) <= 4 ||                                \
            GET_MODE_CLASS (MODE) == MODE_FLOAT &&                      \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0 ||         \ 
            ((REGNO) & 3) == 0)                                         \
          : GET_MODE_SIZE (MODE) <= 4  ||                               \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0) ||        \
            ((REGNO) & 3) == 0                                          \
       : 1)
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote:

>There is nothing wrong with requiring aligned registers, it is just
suboptimal.

The original question had to do with long double which according to the ACD
must be aligned on a 128 bit boundary. This is what works for long double.
If I'm missing something else, please refresh my memory, as it has been
over four months since I looked at this.

/* 
 * Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
 * 32 bit reg/subreg can fit in any general register. On PA1.0, FP regs
 * are 64 bits wide, but 32 bit quantities must be in the leftmost 32
 * bits of the FP register. On PA1.1, FP regs are still 64 bits wide,
 * but both halves can contain 32 bit quantities. In gcc, these registers
 * are each treated as a separate 32 bit FP register. So, modes greater
 * than 32 bits must be aligned on "even" registers. 128 bit floating
 * point must be aligned in evenly aligned FP registers on PA 1.0 and
 * because of the remapping for PA1.1, registers evenly divisible by 4.
 * For PA 1.0, disallow wide non-floating point modes in FP registers.
 */
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
  ((REGNO) == 0                                                         \
    ? (MODE) == CCmode || (MODE) == CCFPmode                            \
    : FP_REGNO_P (REGNO)                                                \
       ? !TARGET_PA_11                                                  \
          ? GET_MODE_SIZE (MODE) <= 4 ||                                \
            GET_MODE_CLASS (MODE) == MODE_FLOAT &&                      \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0 ||         \
            ((REGNO) & 3) == 0)                                         \
          : GET_MODE_SIZE (MODE) <= 4  ||                               \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0) ||        \
            ((REGNO) & 3) == 0                                          \
       : 1)


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  In message < 4.1.19990824214047.00ce42e0@garfield.dis.com >you write:
  > At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote:
  > 
  > >There is nothing wrong with requiring aligned registers, it is just
  > suboptimal.
  > 
  > The original question had to do with long double which according to the ACD
  > must be aligned on a 128 bit boundary. This is what works for long double.
  > If I'm missing something else, please refresh my memory, as it has been
  > over four months since I looked at this.
Adding additional alignment restrictions for wider types is certainly do-able.

Note that the code in question has changed quite a bit recently in preparation
for PA64 support.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 12:14 AM 8/27/99 -0600, Jeffrey A Law wrote:

>Note that the code in question has changed quite a bit recently in preparation
>for PA64 support.

Where do you stand with your various merges, especially the MPE port? I'd like
to get (at least the core port) into a release so I can relax about trying to
track all the changes coming from Jerry and you. I converted FUNCTION_ARG
from a 
macro to a procedure call to try to simplify life (you're right ... it did
take a few readings to understand it, and I'm not sure I understand all of
it :-)), and I'm sure that is also an area that is being worked on for 
PA 2.0.

I'd be happy to resubmit my patches if that'll make life easier for you. It
may take a few days to break them down into separate core port, long double
changes, and millicode performance changes due to current scheduling issues.

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  In message < 4.1.19990827070612.00c4bc00@garfield.dis.com >you write:
  > Where do you stand with your various merges, especially the MPE port? I'd l
My queue is over 200 patches deep.  And unfortunately MPE isn't anywhere near
the top of the list.  Simply a matter of priorities.

  > track all the changes coming from Jerry and you. I converted FUNCTION_ARG
  > from a 
:-)  I did something similar already.  We're still beating on it internally
before we contribute it.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 03:59 PM 8/27/99 -0600, Jeffrey A Law wrote:

>My queue is over 200 patches deep.  And unfortunately MPE isn't anywhere near
>the top of the list.  Simply a matter of priorities.

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.

>:-)  I did something similar already.  We're still beating on it internally
>before we contribute it.

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:

struct rtx_def *
function_arg(cum, mode, type, named)
  const CUMULATIVE_ARGS *cum;
  enum machine_mode mode;
  tree type;
  int named;
{
  rtx reg = 0;
  int basereg1 = 0;
  int basereg2 = 0;

  /*
   * See if there is at least one argument register still available.
   */
  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) 
      {
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
          /*
           * This is a multi-word parameter. If this is either a direct
           * call or the portable runtime and we're dealing with the
           * hardware FPU, place the argument in the argument into the
           * correct FARG, otherwise put it in a general register.
           */
          if ((!cum->indirect           || 
               TARGET_PORTABLE_RUNTIME) &&
               (mode) == DFmode         &&
               !TARGET_SOFT_FLOAT)
              basereg1 = (cum->words ? 38 : 34);
          else 
              basereg1 = (cum->words ? 23 : 25);
        }
      else 
        {
        /*
         * This is a single-word parameter. If this is either a direct
         * call or the portable runtime and we're dealing with the
         * hardware FPU, place the argument into the correct FARG,
         * otherwise put it into a general register.
         */
        if ((!cum->indirect             ||
             TARGET_PORTABLE_RUNTIME)   &&
             (mode) == SFmode           &&
             !TARGET_SOFT_FLOAT)
            basereg1 = (32 + 2 * cum->words);
        else 
            basereg1 = (27 - cum->words - FUNCTION_ARG_SIZE(mode, type));

        }
      /*
       * Generate the REG rtx for the current parameter.
       */
      reg = gen_rtx_REG (mode, basereg1);
      }
    else
      {
      /*
       * We need to place the argument in both floating args as well
       * as the general args.
       */
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
        basereg1 = (cum->words ? 38 : 34);
        basereg2 = (cum->words ? 23 : 25);
        }
      else
        {
        basereg1 = (32 + 2 * cum->words);
        basereg2 = (27 - cum->words - FUNCTION_ARG_SIZE (mode, type));
        }

      reg = gen_rtx_PARALLEL (mode, 
                gen_rtvec(2, 
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg1),
                                       const0_rtx),
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg2),
                                       const0_rtx)));
      }
    }
    return reg;
}
/DIS/GNU/src/egcs-ss/gcc/config/pa(134): 

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  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

Re: MPE Port (was HARD_REGNO_MODE_OK)

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

Yes. Before I do so, I have one small problem to resolve. Maybe you could
provide a suggestion or "better way" to approach it.

libio/gen-params tries to determine if __printf_fp() exists by simply
compiling a small test program. That is not sufficient on MPE because
MPE does late binding. (I run into this with all configure scripts and
in discussions with Ben, it was decided that my best approach is to
have a customized autoconf and build my own configure scripts before
building). That doesn't work here since gen-params is a hard coded
script. I don't want to modify it because I'll no doubt break it
for all other platforms.

Thanks,

M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port (was HARD_REGNO_MODE_OK)

[Jeffrey A Law]

  In message < 4.1.19990829152111.00c4f4c0@garfield.dis.com >you write:
  > At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:
  > 
  > >So let's start with just your new config files and configure.in fragment
  > >first.  Can you send just those pieces?
  > 
  > Yes. Before I do so, I have one small problem to resolve. Maybe you could
  > provide a suggestion or "better way" to approach it.
  > 
  > libio/gen-params tries to determine if __printf_fp() exists by simply
  > compiling a small test program. That is not sufficient on MPE because
  > MPE does late binding. (I run into this with all configure scripts and
  > in discussions with Ben, it was decided that my best approach is to
  > have a customized autoconf and build my own configure scripts before
  > building). That doesn't work here since gen-params is a hard coded
  > script. I don't want to modify it because I'll no doubt break it
  > for all other platforms.
This is the kind of issue I'd punt for now.  Use some kind of hack in your
local tree and we can try to deal with it after we've dealt with the easy
stuff.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  In message < 4.1.19990827070612.00c4bc00@garfield.dis.com >you write:
  > Where do you stand with your various merges, especially the MPE port? I'd l
My queue is over 200 patches deep.  And unfortunately MPE isn't anywhere near
the top of the list.  Simply a matter of priorities.

  > track all the changes coming from Jerry and you. I converted FUNCTION_ARG
  > from a 
:-)  I did something similar already.  We're still beating on it internally
before we contribute it.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  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

Re: MPE Port (was HARD_REGNO_MODE_OK)

[Jeffrey A Law]

  In message < 4.1.19990829152111.00c4f4c0@garfield.dis.com >you write:
  > At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:
  > 
  > >So let's start with just your new config files and configure.in fragment
  > >first.  Can you send just those pieces?
  > 
  > Yes. Before I do so, I have one small problem to resolve. Maybe you could
  > provide a suggestion or "better way" to approach it.
  > 
  > libio/gen-params tries to determine if __printf_fp() exists by simply
  > compiling a small test program. That is not sufficient on MPE because
  > MPE does late binding. (I run into this with all configure scripts and
  > in discussions with Ben, it was decided that my best approach is to
  > have a customized autoconf and build my own configure scripts before
  > building). That doesn't work here since gen-params is a hard coded
  > script. I don't want to modify it because I'll no doubt break it
  > for all other platforms.
This is the kind of issue I'd punt for now.  Use some kind of hack in your
local tree and we can try to deal with it after we've dealt with the easy
stuff.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Jeffrey A Law]

  In message < 4.1.19990824214047.00ce42e0@garfield.dis.com >you write:
  > At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote:
  > 
  > >There is nothing wrong with requiring aligned registers, it is just
  > suboptimal.
  > 
  > The original question had to do with long double which according to the ACD
  > must be aligned on a 128 bit boundary. This is what works for long double.
  > If I'm missing something else, please refresh my memory, as it has been
  > over four months since I looked at this.
Adding additional alignment restrictions for wider types is certainly do-able.

Note that the code in question has changed quite a bit recently in preparation
for PA64 support.

jeff

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 12:14 AM 8/27/99 -0600, Jeffrey A Law wrote:

>Note that the code in question has changed quite a bit recently in preparation
>for PA64 support.

Where do you stand with your various merges, especially the MPE port? I'd like
to get (at least the core port) into a release so I can relax about trying to
track all the changes coming from Jerry and you. I converted FUNCTION_ARG
from a 
macro to a procedure call to try to simplify life (you're right ... it did
take a few readings to understand it, and I'm not sure I understand all of
it :-)), and I'm sure that is also an area that is being worked on for 
PA 2.0.

I'd be happy to resubmit my patches if that'll make life easier for you. It
may take a few days to break them down into separate core port, long double
changes, and millicode performance changes due to current scheduling issues.

Regards,


M.
--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port (was HARD_REGNO_MODE_OK)

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

Yes. Before I do so, I have one small problem to resolve. Maybe you could
provide a suggestion or "better way" to approach it.

libio/gen-params tries to determine if __printf_fp() exists by simply
compiling a small test program. That is not sufficient on MPE because
MPE does late binding. (I run into this with all configure scripts and
in discussions with Ben, it was decided that my best approach is to
have a customized autoconf and build my own configure scripts before
building). That doesn't work here since gen-params is a hard coded
script. I don't want to modify it because I'll no doubt break it
for all other platforms.

Thanks,

M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 08:37 PM 8/24/99 -0600, Jeffrey A Law wrote:

>There is nothing wrong with requiring aligned registers, it is just
suboptimal.

The original question had to do with long double which according to the ACD
must be aligned on a 128 bit boundary. This is what works for long double.
If I'm missing something else, please refresh my memory, as it has been
over four months since I looked at this.

/* 
 * Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
 * 32 bit reg/subreg can fit in any general register. On PA1.0, FP regs
 * are 64 bits wide, but 32 bit quantities must be in the leftmost 32
 * bits of the FP register. On PA1.1, FP regs are still 64 bits wide,
 * but both halves can contain 32 bit quantities. In gcc, these registers
 * are each treated as a separate 32 bit FP register. So, modes greater
 * than 32 bits must be aligned on "even" registers. 128 bit floating
 * point must be aligned in evenly aligned FP registers on PA 1.0 and
 * because of the remapping for PA1.1, registers evenly divisible by 4.
 * For PA 1.0, disallow wide non-floating point modes in FP registers.
 */
#define HARD_REGNO_MODE_OK(REGNO, MODE) \
  ((REGNO) == 0                                                         \
    ? (MODE) == CCmode || (MODE) == CCFPmode                            \
    : FP_REGNO_P (REGNO)                                                \
       ? !TARGET_PA_11                                                  \
          ? GET_MODE_SIZE (MODE) <= 4 ||                                \
            GET_MODE_CLASS (MODE) == MODE_FLOAT &&                      \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0 ||         \
            ((REGNO) & 3) == 0)                                         \
          : GET_MODE_SIZE (MODE) <= 4  ||                               \
            (GET_MODE_SIZE (MODE) <= 8 && ((REGNO) & 1) == 0) ||        \
            ((REGNO) & 3) == 0                                          \
       : 1)


--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: HARD_REGNO_MODE_OK on PA-RISC (revisited)

[Mark Klein]

At 03:59 PM 8/27/99 -0600, Jeffrey A Law wrote:

>My queue is over 200 patches deep.  And unfortunately MPE isn't anywhere near
>the top of the list.  Simply a matter of priorities.

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.

>:-)  I did something similar already.  We're still beating on it internally
>before we contribute it.

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:

struct rtx_def *
function_arg(cum, mode, type, named)
  const CUMULATIVE_ARGS *cum;
  enum machine_mode mode;
  tree type;
  int named;
{
  rtx reg = 0;
  int basereg1 = 0;
  int basereg2 = 0;

  /*
   * See if there is at least one argument register still available.
   */
  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) 
      {
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
          /*
           * This is a multi-word parameter. If this is either a direct
           * call or the portable runtime and we're dealing with the
           * hardware FPU, place the argument in the argument into the
           * correct FARG, otherwise put it in a general register.
           */
          if ((!cum->indirect           || 
               TARGET_PORTABLE_RUNTIME) &&
               (mode) == DFmode         &&
               !TARGET_SOFT_FLOAT)
              basereg1 = (cum->words ? 38 : 34);
          else 
              basereg1 = (cum->words ? 23 : 25);
        }
      else 
        {
        /*
         * This is a single-word parameter. If this is either a direct
         * call or the portable runtime and we're dealing with the
         * hardware FPU, place the argument into the correct FARG,
         * otherwise put it into a general register.
         */
        if ((!cum->indirect             ||
             TARGET_PORTABLE_RUNTIME)   &&
             (mode) == SFmode           &&
             !TARGET_SOFT_FLOAT)
            basereg1 = (32 + 2 * cum->words);
        else 
            basereg1 = (27 - cum->words - FUNCTION_ARG_SIZE(mode, type));

        }
      /*
       * Generate the REG rtx for the current parameter.
       */
      reg = gen_rtx_REG (mode, basereg1);
      }
    else
      {
      /*
       * We need to place the argument in both floating args as well
       * as the general args.
       */
      if (FUNCTION_ARG_SIZE (mode, type) > 2)
        {
          /*
           * We're dealing with an argument greater than 2 words.
           * It must be passed in the frame by reference.
           */
          return 0;
        }

      if (FUNCTION_ARG_SIZE (mode, type) > 1)
        {
        basereg1 = (cum->words ? 38 : 34);
        basereg2 = (cum->words ? 23 : 25);
        }
      else
        {
        basereg1 = (32 + 2 * cum->words);
        basereg2 = (27 - cum->words - FUNCTION_ARG_SIZE (mode, type));
        }

      reg = gen_rtx_PARALLEL (mode, 
                gen_rtvec(2, 
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg1),
                                       const0_rtx),
                    gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_REG (mode, basereg2),
                                       const0_rtx)));
      }
    }
    return reg;
}
/DIS/GNU/src/egcs-ss/gcc/config/pa(134): 

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

OK - I've reformatted and will repost momentarily. These are either the
new config files or changes to configure.in. There are also some MPE
specific README/scripts that I'm not sure how best to deal with. These
address the fact that some of the tools need customization for MPE before
they'll work. I'll post them as I have them at this moment and will change 
them as you see fit.

libobjc/thr-dce.c needs a small change and I've sent that along with
this as it could affect other DCE ports as well.

I'll sit on pa.c, pa.h and pa.md until I hear otherwise from you.

Thanks!

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available			

Re: MPE Port

[Mark Klein]

At 04:08 AM 8/29/99 -0600, Jeffrey A Law wrote:

>So let's start with just your new config files and configure.in fragment
>first.  Can you send just those pieces?

OK - I've reformatted and will repost momentarily. These are either the
new config files or changes to configure.in. There are also some MPE
specific README/scripts that I'm not sure how best to deal with. These
address the fact that some of the tools need customization for MPE before
they'll work. I'll post them as I have them at this moment and will change 
them as you see fit.

libobjc/thr-dce.c needs a small change and I've sent that along with
this as it could affect other DCE ports as well.

I'll sit on pa.c, pa.h and pa.md until I hear otherwise from you.

Thanks!

Regards,


M.

--
Mark Klein                                 DIS International, Ltd.
http://www.dis.com                         415-892-8400
PGP Public Key Available