PRE_DEC, POST_INC

[Florent Defay]

Hi,

I am working on a new port.

The target machine supports post-increment and pre-decrement
addressing modes. These modes are twice faster than indexed mode.
It is important for us that GCC consider them well.

I wrote emails to gcc-help and I was told that GCC was not so good at
pre/post-dec/increment since few targets support these modes.

I would like to know if there is a good way to make pre-dec and
post-inc modes have more priority than indexed mode.
Is there current work for dealing with this issue ?

Thank you.

Regards.

Florent

Re: PRE_DEC, POST_INC

[Florent Defay]

Thank you.

> I am assuming you already have basic generation of auto-incs and you
> have your definitions for legitimate{legitimize}_address all set up
> correctly.

Well, I think they are. But the problem could be this. Here are cuts
from the machine description dealing with auto-inc-dec:

#define HAVE_PRE_INCREMENT  0
#define HAVE_PRE_DECREMENT  1
#define HAVE_POST_INCREMENT 1
#define HAVE_POST_DECREMENT 0

int
tam16_legitimate_address_p (enum machine_mode mode ATTRIBUTE_UNUSED,
rtx x, int strict)
{
  rtx op1,op2;

  /* Post-inc and pre-dec addressing modes allowed. */
  if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
  && REG_P (XEXP (x, 0))
  && (strict ? REG_OK_FOR_BASE_STRICT_P (XEXP (x, 0))
  : REG_OK_FOR_BASE_NOSTRICT_P (XEXP (x, 0)))
  /*&& reload_completed*/)
  {
return 1;
  }
...

The legitimize address function is defined as the legitimate address
function. I took inspiration from msp430's md.
#define LEGITIMIZE_ADDRESS(X, OLDX, MODE, WIN)  \
  GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN)

> In this case you could start by tweaking your address costs macros.

I did. Here again I could be wrong in the implementation:

int
tam16_address_costs (rtx x)
{
  switch (GET_CODE (x))
  {
case REG:
  /* (rn) */
  return COSTS_N_INSNS (2);
  break;

case PLUS:
  /* X(rn) */
  return COSTS_N_INSNS (4);
  break;

case POST_INC:
case PRE_DEC:
  /* -(rn) , (rn)+ */
  return COSTS_N_INSNS (2);
  break;

default:
  break;
  }

  if (CONSTANT_ADDRESS_P (x))
  {
return COSTS_N_INSNS (4);
  }

  /* Unknown addressing mode. */
  debug_rtx (x);
  return COSTS_N_INSNS (50);
}

According to you, is this enough to enable basic auto-inc-dec in GCC ?
I tried to compile some test-cases I found in emails about the
subject. The result is there is no pre-dec or post-inc generated at
all.

Regards.

Florent

real_format_for_mode / Porting GCC on a new arch

[Florent DEFAY]

Hi,

I would like to know more about REAL_MODE_FORMAT and real_format_for_mode.

I'm sorry because I already posted this email in gcc-help mailing-list
but there was no answer and maybe its right place is here ?

I am working on a port of GCC. The new xgcc generated crashes this way :

Program received signal SIGSEGV, Segmentation fault.
builtin_define_float_constants (name_prefix=0x83fcaf9 "FLT",
fp_suffix=0x8419523 "F", fp_cast=0x84109dd "%s", type=0xb7c0a410) at
../../gcc-4.3.3/gcc/c-cppbuiltin.c:108
108   gcc_assert (fmt->b != 10);

because fmt = 0.

This fmt results of
 fmt = REAL_MODE_FORMAT (TYPE_MODE (type));

and REAL_MODE_FORMAT is defined this way :

#define REAL_MODE_FORMAT(MODE)  \
 (real_format_for_mode[DECIMAL_FLOAT_MODE_P (MODE) \
   ? ((MODE - MIN_MODE_DECIMAL_FLOAT)  \
  + (MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1)) \
   : (MODE - MIN_MODE_FLOAT)])

But I did not find definition for real_format_for_mode, just an
"extern" in real.h (nothing in real.c) :

extern const struct real_format *
 real_format_for_mode[MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1
  + MAX_MODE_DECIMAL_FLOAT - MIN_MODE_DECIMAL_FLOAT + 1];


Should I include an implementation of real_format_for_mode in my
target.c ? If I should, how can I do that ? If not, how to avoid this
crash ? Any idea ?

Thank you.

Florent