PATCH: Request for comments

Jeffrey A Law
Wed Jun 30 23:15:00 GMT 1999

  In message < >you write:
  > How does this work on SMALL_REGISTER_CLASS machines that pass
  > arguments in registers?  It appears as if emit_library_call
  > will generate
Good question.

I started groping around with my favorite S_R_C machine that passes args in
registers (mn103).  It defines TARGET_MEM_FUNCTIONS (via svr4.h), so it will
not trigger this kind of problem.  This probably true of most of the newer

Anyway, I hacked the mn103 up to not define TARGET_MEM_FUNCTIONS and got the
following in the .rtl dump:

(insn 65 63 67 (set (reg:SI 0 d0)
        (symbol_ref:SI ("data_tmp"))) -1 (nil)

(insn 67 65 68 (set (reg:SI 1 d1)
        (reg/v:SI 15)) -1 (nil)

(insn 68 67 70 (set (reg/v:SI 15)
        (plus:SI (reg/v:SI 15)
            (const_int 404 [0x194]))) -1 (nil)

(call_insn 70 68 73 (call (mem:QI (symbol_ref:SI ("bcopy")) 0)
        (const_int 12 [0xc])) -1 (nil)
    (expr_list (use (reg:SI 1 d1))
        (expr_list (use (reg:SI 0 d0))

So, the answer is, yes, S_R_C machines which pass arguments in registers and
do not define TARGET_MEM_FUNCTIONS could potentially lose.  I do not think
the new reload code directly helps this problem (it helps indirectly by
reducing spills, but it does not directly address this problem).

For reference the thumb, c4x, dsp16xx, h8300, i386, mips16, mn102, mn103,
ns32, pdp11 & sh currently define (or conditionally define) S_R_C.

Of those ports, the thumb, c4x, dsp16xx, h8300, mips, mn102, mn103 & sh
appear to unconditionally define TARGET_MEM_FUNCTIONS and are safe.

The remaining ports (i386, ns32k, pdp11) do not normally pass parameters in

I think this explains why nobody's ever tripped this bug.

I would actually like to make TARGET_MEM_FUNCTIONS always true, but I haven't
looked into how much work that would really be.


More information about the Gcc-patches mailing list