Re: PRE_DEC, POST_INC
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
PRE_DEC, POST_INC
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
On Fri, Aug 7, 2009 at 1:33 PM, Florent Defayspira.inhabit...@gmail.com wrote:
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.
GCC does support generation of pre{post}-inc {dec}. GCC's auto-inc
detector works at a basic block level and attempts to generate
auto-inc operations within a basic block . Look at auto-inc-dec.c for
more information.It is an area which could do with some improvement
and work , however no one's found the time to do it yet.
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 ?
I am assuming you already have basic generation of auto-incs and you
have your definitions for legitimate{legitimize}_address all set up
correctly.
In this case you could start by tweaking your address costs macros.
Getting that right can help you get going in the right direction with
the current state of the art. In a previous life while maintaining a
private port of GCC I've dabbled with a few patches posted by Joern
Reneccke with regards to auto-inc-dec that worked well for me in
improving code generation on some of the benchmarks. You should be
able to get them out using Google.
There are a number of bugzilla entries in the database that cover a
number of cases for auto-inc generation and some ideas on what can be
done to improve this. You might be better off searching in that as
well. One of the problems upto 4.3 was that the ivopts and the loop
optimizers didn't care too much about auto-increment addressing and
thereby pessimizing this in favour of using index addressing. There
have been a few patches that were being discussed in in the recent
past by Bernd Schmidt and Zdenek attempting to address auto-inc
generation for loop ivopts but I'm not sure if these have gone into
trunk yet.
Hope this helps.
cheers
Ramana
RE: PRE_DEC, POST_INC
I asked similar question regarding PRE_INC/POST_INC quite a while ago,
and there were quite some discussions. Haven't check whether the situation
changed.
http://gcc.gnu.org/ml/gcc/2007-11/msg00032.html
Bingfeng Mei
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
Behalf Of Ramana Radhakrishnan
Sent: 07 August 2009 14:11
To: Florent Defay
Cc: gcc@gcc.gnu.org
Subject: Re: PRE_DEC, POST_INC
On Fri, Aug 7, 2009 at 1:33 PM, Florent
Defayspira.inhabit...@gmail.com wrote:
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.
GCC does support generation of pre{post}-inc {dec}. GCC's auto-inc
detector works at a basic block level and attempts to generate
auto-inc operations within a basic block . Look at auto-inc-dec.c for
more information.It is an area which could do with some improvement
and work , however no one's found the time to do it yet.
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 ?
I am assuming you already have basic generation of auto-incs and you
have your definitions for legitimate{legitimize}_address all set up
correctly.
In this case you could start by tweaking your address costs macros.
Getting that right can help you get going in the right direction with
the current state of the art. In a previous life while maintaining a
private port of GCC I've dabbled with a few patches posted by Joern
Reneccke with regards to auto-inc-dec that worked well for me in
improving code generation on some of the benchmarks. You should be
able to get them out using Google.
There are a number of bugzilla entries in the database that cover a
number of cases for auto-inc generation and some ideas on what can be
done to improve this. You might be better off searching in that as
well. One of the problems upto 4.3 was that the ivopts and the loop
optimizers didn't care too much about auto-increment addressing and
thereby pessimizing this in favour of using index addressing. There
have been a few patches that were being discussed in in the recent
past by Bernd Schmidt and Zdenek attempting to address auto-inc
generation for loop ivopts but I'm not sure if these have gone into
trunk yet.
Hope this helps.
cheers
Ramana
note_stores vs. PRE_DEC, POST_INC and so on
The comment for note_stores() (in rtlanal.c) says: /* Call FUN on each register or MEM that is stored into or clobbered by X. (X would be the pattern of an insn). But this doesn't happen when a register is modified by e.g. a PRE_DEC expression. Is this an oversight or intentional? If intentional, the comment should say so and perhaps also why. -- Rask Ingemann Lambertsen
Re: note_stores vs. PRE_DEC, POST_INC and so on
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes: The comment for note_stores() (in rtlanal.c) says: /* Call FUN on each register or MEM that is stored into or clobbered by X. (X would be the pattern of an insn). But this doesn't happen when a register is modified by e.g. a PRE_DEC expression. Is this an oversight or intentional? If intentional, the comment should say so and perhaps also why. The note_stores interface doesn't really provide a way to handle PRE_DEC or other such expressions. We could change that by redefining the interface, but we would need to audit all the calls to note_stores. That would be a good idea in any case since it is certainly possible, even likely, that some of them should be handle autoincrement expressions but aren't. Ian
