public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Tim Rye <timjrye@gmail.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Can be gcc portable to architecture without indexed addressing mode?
Date: Wed, 01 Aug 2012 13:08:00 -0000	[thread overview]
Message-ID: <CAKOQZ8yc2f6f831r6UqZ7wgYh4W2znZTy_GXSUgNgUVk1OdrHA@mail.gmail.com> (raw)
In-Reply-To: <CAP6CXZckghfHWQWwnfHzEYY0p0cFrb_j9j9-98NW5_XXUA0g+A@mail.gmail.com>

On Wed, Aug 1, 2012 at 4:57 AM, Tim Rye <timjrye@gmail.com> wrote:
>
> I too am porting GCC (working on 4.7.1) to a new architecture which
> has no indexed addressing mode. I cannot seem to stop GCC from
> generating RTL such as (mem:XX (plus:XX (reg:XX ...) (const_int XX))).
> This is clearly invalid for a machine with no indexed addressing mode.

You should not be seeing such addresses if your legitimate_address_p
target hook rejects them.

> I have tried defining the following macros as I think they need to be
> defined, but it doesn't seem to work:
>
> #define BASE_REG_CLASS WRITEABLE_REGS
> #define MODE_BASE_REG_REG_CLASS(MODE) NO_REGS
> #define INDEX_REG_CLASS NO_REGS
> #ifdef REG_OK_STRICT
> #define REGNO_OK_FOR_BASE_P(NUM) mytarget_regno_ok_for_base_p(NUM,1)
> #else
> #define REGNO_OK_FOR_BASE_P(NUM) mytarget_regno_ok_for_base_p(NUM,0)
> #endif
> #define REGNO_MODE_OK_FOR_REG_BASE_P(NUM, MODE) 0
> #define REGNO_OK_FOR_INDEX_P(NUM) 0
>
> Are these definitions correct for the situation I describe? And if so,
> what else would I need to define to stop GCC using indexed addressing?
> Or, if they are not correct, could you describe what I need to do
> instead?
>
> My TARGET_LEGITIMATE_ADDRESS_P hook returns false when the code of the
> operand is PLUS.

That all looks fine.

I know it is possible to write a port for a target without indexed
addressing, because I've done it myself.  Obviously the generated code
is not very good.  I don't recall any particular magic involved.  The
reload pass should be able to cope by reloading the offset into a
register and adding it in.  It may help to play with
LEGITIMIZE_RELOAD_ADDRESS, but I don't think it is required.

I think you are going to have to start debugging what the compiler is
doing.  In particular, look at the dumps for the passes after reload.
Does the invalid address somehow survive reload, or does it somehow
get introduce afterward?

Ian

  reply	other threads:[~2012-08-01 13:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-01 11:57 Tim Rye
2012-08-01 13:08 ` Ian Lance Taylor [this message]
2012-08-01 14:54   ` Tim Rye
2012-08-01 15:02     ` Ian Lance Taylor
  -- strict thread matches above, loose matches on Subject: below --
2010-03-17  7:51 이환희
2010-03-17 15:18 ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKOQZ8yc2f6f831r6UqZ7wgYh4W2znZTy_GXSUgNgUVk1OdrHA@mail.gmail.com \
    --to=iant@google.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=timjrye@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).