Re: [patch] Address-space-aware base registers (Re: m32c support for named addr spaces branch)

["Ulrich Weigand" <uweigand@de.ibm.com>]

DJ Delorie wrote:

> In r8c/m16c mode, A0/A1 are 16 bit, and pointers are normally 16 bit.
> There are extra opcodes for load/store with 32-bit pointers in A1A0.
> In m32cm/m32c mode, pointers are normally 24 bit, A0 and A1 are 24
> bit, and there are no extra opcodes.
> 
> The extra opcodes support 32-bit pointers *without* offsets, or 16-bit
> pointers *with* 24-bit offsets.  In either case, A0 is the only base
> register (or A1A0 for 32-bit pointers).

Ah, thanks for the explanation.  I think what you need to do to model
this in MODE_CODE_BASE_REG_CLASS is to look at the OUTER_CODE: if this
is a ZERO_EXTEND, the actual base variable is HImode, and you need to
restrict the base-reg class to A0_REGS.  Otherwise, the base variable
is SImode and you need to allow A_REGS.

In either case, REGNO_MODE_CODE_OK_FOR_BASE_P should accept only the
register A0.

> Note that the base register class was A_REGS (A1 and A0) before, and
> it picked R1.  Go figure.
> 
> I tried allowing A_REGS for the appropriate cases, now I get:
> 
> dj.c: In function 'far_array_set':
> dj.c:76:1: error: unrecognizable insn:
> (insn 20 19 14 2 dj.c:75 (set (mem/s/j:QI (plus:SI (reg:SI 0 r0)
>                 (symbol_ref:SI ("far_char_array") [flags 0x40] <var_decl 0xb7e93170 far_char_array>)) [0 far_char_array S1 A8 AS1])
>         (reg:QI 2 r1)) -1 (nil))
> 
> 
> It seems to be trying every register EXCEPT the ones in the base
> class.

I cannot reproduce this; can you send me the exact patch you're using
to get this?

I've tried your test case with the modification to MODE_CODE_BASE_REG_CLASS
as above.  I'm now running into a different problem:

dj.c: In function 'far_array_set':
dj.c:8:1: error: insn does not satisfy its constraints:
(insn 11 16 14 2 dj.c:7 (set (mem/s/j:QI (reg:SI 4 a0) [0 far_char_array S1 A8 AS1])
        (const_int 0 [0x0])) 89 {movqi_op} (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))
dj.c:8:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

What has happened here is that reload thought it could use the 7th alternative (Sd / i)
of the movqi_op insn pattern:

(define_insn "movqi_op"
  [(set (match_operand:QI 0 "m32c_nonimmediate_operand"
                          "=SF,Rhi*RmmSd, Rqi*Rmm, <,          RqiSd*Rmm, SdSs,    Rqi*Rmm, Sd")
        (match_operand:QI 1 "m32c_any_operand"
                          "Rhi*RmmSd,SF, iRqi*Rmm, iRqiSd*Rmm, >,         Rqi*Rmm, SdSs,    i"))]
  "m32c_mov_ok (operands, QImode)"

Now, Sd rejects the operand because it only support generic addresses.
However, Sd is marked as EXTRA_MEMORY_CONSTRAINT, which per definition
means that *every* memory reference whose address is simply a base register
must be accepted.  Reload relies on that promise and reloads the address
into a base register (note that is does choose A0 as requested), but then
Sd still rejects the reloaded value ...

The problem is that the definition of EXTRA_MEMORY_CONSTRAINT really does
not take address spaces into account.  In the presence of multiple address
spaces, a promise to accept every memory reference (of any address space)
whose address is simply a base register is probably hard to fulfil.

I see two ways to resolve this issue:

- Either we make memory (and address) constraints address-space aware.
  For example, we could have a new target macro EXTRA_CONSTRAINT_ADDR_SPACE
  that returns the (sole) address space which is accepted by the constraint.
  (Generic constraints would only accept the generic address space.)

- Or else, we say this must be resolved by the back-end by never accepting
  memory operands of different address spaces in the same insn.  In general,
  there's probably not much use to this anyway -- reload will never be able
  to replace a memory operand of one address space with one of another.
  This means the back-end would need to provide different insn patterns
  to deal with different address spaces, and would need to enforce this
  at the predicate level, not the constraint level.

Thoughts?

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com