Can be gcc portable to architecture without indexed addressing mode?

Can be gcc portable to architecture without indexed addressing mode?

[이환희]

Hello.

I have to start to make some c compiler for my own cpu. This cpu has
very simple core and has many limitations.

I think that many of those limitations are evitable in source coding.
But I cannot convince a few of them.

Instructions of this cpu core have no indexed addressing mode like
'base' + 'offset'.

This cpu can address memories only according to followings.

  immediate addressing
  indirect addressing with general registers

I really want to know that gcc is portable on this core in spite of
the limitation.

Without indexed addressing mode, in addressing local variables on
stack, or accessing array,

it's even very difficult to write hand assemble code.

So I need to know that gcc can overcome this limitation.

Please help me.

Re: Can be gcc portable to architecture without indexed addressing mode?

[Andrew Haley]

On 03/17/2010 06:19 AM, 이환희 wrote:
> Hello.
> 
> I have to start to make some c compiler for my own cpu. This cpu has
> very simple core and has many limitations.
> 
> I think that many of those limitations are evitable in source coding.
> But I cannot convince a few of them.
> 
> Instructions of this cpu core have no indexed addressing mode like
> 'base' + 'offset'.
> 
> This cpu can address memories only according to followings.
> 
>   immediate addressing
>   indirect addressing with general registers
> 
> I really want to know that gcc is portable on this core in spite of
> the limitation.

It is, but the generated code is going to be very poor.

Andrew.

Re: Can be gcc portable to architecture without indexed addressing mode?

[Ian Lance Taylor]

On Wed, Aug 1, 2012 at 7:53 AM, Tim Rye <timjrye@gmail.com> wrote:
>
> static bool mytarget_legitimate_address_p(enum machine_mode mode, rtx
> x, bool strict) {
>
>   while (GET_CODE(x) == MEM)
>     x = XEXP(x,0);

That definitely does not look right.  Accepting a MEM here means that
your instructions accept addresses stored in memory.  That is a very
unusual addressing mode.


> mul.c:37:1: internal compiler error: in change_address_1, at emit-rtl.c:1996
>
> The stack trace at this point looks like this:
>
> -------------
>
> (gdb) where
> #0  fancy_abort (file=0xb2c8c8
> "../../gcc-4.7.1-mytarget/gcc/emit-rtl.c", line=1996,
>     function=0xb2ca20 "change_address_1") at
> ../../gcc-4.7.1-mytarget/gcc/diagnostic.c:898
> #1  0x00000000005c4109 in change_address_1 (memref=0x2a95691a08,
> mode=HImode, addr=0x2a956919f0,

> #5  0x00000000005e80c5 in emit_move_insn_1 (x=0x2a9568c420, y=0x2a95691960)
>     at ../../gcc-4.7.1-mytarget/gcc/expr.c:3417

This suggests that your move insn needs special handling during
reload.  That is fairly common, as reload invokes the move insn
itself.  Read the description of movm closely in
http://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html#Standard-Names
.  Look at examples for similar processors.

Ian

Re: Can be gcc portable to architecture without indexed addressing mode?

[Tim Rye]

Hi Ian,

Thanks for the speedy response.

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

I'm pretty certain my legitimate_address_p does reject them. It's very
simple, and basically only accepts addresses which are constant or in
registers:

-------------

static bool mytarget_legitimate_address_p(enum machine_mode mode, rtx
x, bool strict) {

  while (GET_CODE(x) == MEM)
    x = XEXP(x,0);

  if (CONSTANT_P(x))
    return true;

  if (GET_CODE(x) == SUBREG && !strict)
    x = SUBREG_REG(x);

  if (GET_CODE(x) == REG) {

    if (!strict)
      return true;

    int regno = (int) REGNO(x);

    if (regno >= FIRST_PSEUDO_REGISTER && reg_renumber)
      regno = reg_renumber[regno];

    return ((regno >= FIRST_WRITABLE_REG) && (regno <= LAST_WRITABLE_REG));
  }

  return false;
}

-------------

> 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?

I should have mentioned in my first email that the compiler is
actually failing during reload, it isn't able to compile the source
file I give it. I get an ICE:

mul.c:37:1: internal compiler error: in change_address_1, at emit-rtl.c:1996

The stack trace at this point looks like this:

-------------

(gdb) where
#0  fancy_abort (file=0xb2c8c8
"../../gcc-4.7.1-mytarget/gcc/emit-rtl.c", line=1996,
    function=0xb2ca20 "change_address_1") at
../../gcc-4.7.1-mytarget/gcc/diagnostic.c:898
#1  0x00000000005c4109 in change_address_1 (memref=0x2a95691a08,
mode=HImode, addr=0x2a956919f0,
    validate=1) at ../../gcc-4.7.1-mytarget/gcc/emit-rtl.c:1996
#2  0x00000000005c48a8 in replace_equiv_address (memref=0x2a95691a08,
addr=0x2a956919f0)
    at ../../gcc-4.7.1-mytarget/gcc/emit-rtl.c:2207
#3  0x00000000005c2e5a in operand_subword (op=0x2a956919a8, offset=1,
validate_address=1, mode=SImode)
    at ../../gcc-4.7.1-mytarget/gcc/emit-rtl.c:1401
#4  0x00000000005e7dc9 in emit_move_multi_word (mode=SImode,
x=0x2a9568c420, y=0x2a956919a8)
    at ../../gcc-4.7.1-mytarget/gcc/expr.c:3334
#5  0x00000000005e80c5 in emit_move_insn_1 (x=0x2a9568c420, y=0x2a95691960)
    at ../../gcc-4.7.1-mytarget/gcc/expr.c:3417
#6  0x00000000007255bd in gen_move_insn (x=0x2a9568c420, y=0x2a95691960)
    at ../../gcc-4.7.1-mytarget/gcc/optabs.c:4708
#7  0x000000000078cfe3 in gen_reload (out=0x2a9568c420,
in=0x2a95691960, opnum=1, type=RELOAD_FOR_INPUT)
    at ../../gcc-4.7.1-mytarget/gcc/reload1.c:8677
#8  0x000000000078aaa0 in emit_input_reload_insns (chain=0xed9330,
rl=0xe480a8, old=0x2a95679880, j=1)
    at ../../gcc-4.7.1-mytarget/gcc/reload1.c:7563
#9  0x000000000078b48c in do_input_reload (chain=0xed9330, rl=0xe480a8, j=1)
    at ../../gcc-4.7.1-mytarget/gcc/reload1.c:7850
#10 0x000000000078bb63 in emit_reload_insns (chain=0xed9330) at
../../gcc-4.7.1-mytarget/gcc/reload1.c:8042
#11 0x00000000007851f2 in reload_as_needed (live_known=1) at
../../gcc-4.7.1-mytarget/gcc/reload1.c:4655
#12 0x000000000077ddf9 in reload (first=0x2a9567f1c0, global=1)
    at ../../gcc-4.7.1-mytarget/gcc/reload1.c:1057
#13 0x00000000006bf9c2 in do_reload () at
../../gcc-4.7.1-mytarget/gcc/ira.c:3733
#14 0x00000000006bfb4f in rest_of_handle_reload () at
../../gcc-4.7.1-mytarget/gcc/ira.c:3824
#15 0x0000000000738777 in execute_one_pass (pass=0xde2c20) at
../../gcc-4.7.1-mytarget/gcc/passes.c:2084
#16 0x0000000000738abf in execute_pass_list (pass=0xde2c20) at
../../gcc-4.7.1-mytarget/gcc/passes.c:2139
#17 0x0000000000738adb in execute_pass_list (pass=0xde3260) at
../../gcc-4.7.1-mytarget/gcc/passes.c:2140
#18 0x0000000000824e2c in tree_rest_of_compilation (fndecl=0x2a95661200)
    at ../../gcc-4.7.1-mytarget/gcc/tree-optimize.c:422
#19 0x000000000056428e in cgraph_expand_function (node=0x2a9567b000)
    at ../../gcc-4.7.1-mytarget/gcc/cgraphunit.c:1837
#20 0x0000000000564464 in cgraph_expand_all_functions () at
../../gcc-4.7.1-mytarget/gcc/cgraphunit.c:1904
#21 0x0000000000564d8f in cgraph_optimize () at
../../gcc-4.7.1-mytarget/gcc/cgraphunit.c:2218
#22 0x0000000000562eb6 in cgraph_finalize_compilation_unit ()
    at ../../gcc-4.7.1-mytarget/gcc/cgraphunit.c:1344
#23 0x00000000004726a8 in c_write_global_declarations () at
../../gcc-4.7.1-mytarget/gcc/c-decl.c:10032
#24 0x00000000007c41eb in compile_file () at
../../gcc-4.7.1-mytarget/gcc/toplev.c:573
#25 0x00000000007c6166 in do_compile () at
../../gcc-4.7.1-mytarget/gcc/toplev.c:1938
#26 0x00000000007c62ac in toplev_main (argc=4, argv=0x7fbfffedc8)
    at ../../gcc-4.7.1-mytarget/gcc/toplev.c:2014
#27 0x00000000004f5d17 in main (argc=4, argv=0x7fbfffedc8) at
../../gcc-4.7.1-mytarget/gcc/main.c:36

-------------

Does this offer any more clues as to what I've done wrong? Surely
there must be a way to fix this without hacking into GCC's source
code!

Thanks again,
Tim

Re: Can be gcc portable to architecture without indexed addressing mode?

[Ian Lance Taylor]

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

Re: Can be gcc portable to architecture without indexed addressing mode?

[Tim Rye]

Hello,

This question is a followup to a previous question asked in March
2010. I am in a similar situation. The original question was:

> Hello.
>
> I have to start to make some c compiler for my own cpu. This cpu has
> very simple core and has many limitations.
>
> I think that many of those limitations are evitable in source coding.
> But I cannot convince a few of them.
>
> Instructions of this cpu core have no indexed addressing mode like
> 'base' + 'offset'.
>
> This cpu can address memories only according to followings.
>
>   immediate addressing
>   indirect addressing with general registers
>
> I really want to know that gcc is portable on this core in spite of
> the limitation.

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.

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.

(On 17th March 2010, Andrew Haley answered the above question, saying
that it was possible to port GCC for such a machine, but gave no
indication as to how).

Thanks in advance for your help.