[new-regalloc] Go into bootstrap land.
Denis Chertykov
denisc@overta.ru
Wed Apr 10 11:44:00 GMT 2002
Michael Matz <matz@kde.org> writes:
> Hi,
>
> the below patch makes gcc bootstrap again all languages besides Ada
> (untested) after some weeks of breakage. I'm not really sure that
> pre-reload was a that good idea.
Why you think so ?
(IMHO: pre-reload was a good idea because pre-reload makes rtl more
realistic and pre-reload can help to remove reload.)
> One problem e.g. is, that pre-reload handles SCRATCH's and replaces
> them with pseudos.
As I know we will not have any passes between pre-reload
and new-allocator.
IMHO: pre-reload will be something like df.c and pre-reload will be a part
of new-allocator.
I see pre-reload as:
1. Make instruction more realistic:
- add scratch registers;
- make all operands to potentially satisfy constraints ('0','=&', ...);
2. Collect information about all registers based on constraints.
3. ra.c can use constraints based information to handle
'earlyclobbered' operands;
4. We can substitute df.c based information about defs/uses on
pre-reload (constraints) based.
> After allocation there are other passes before reload, which try to
> rerecognize some insns. If those former scratches were in clobbers,
> those insns can't be recognized again, because scratch_operand()
> only accepts SCRATCH and hardregs.
> For now my gross hack makes it accept also pseudos for that
> timeframe, which is not that wrong, as in reality those pseudos have
> all an associated hardreg already, it's just not yet substituted
> into the insns.
May be better to use reg_renumber array inside scratch_operand ?
Something like:
int
scratch_operand (op, mode)
register rtx op;
@@ -1099,7 +1109,7 @@ scratch_operand (op, mode)
return (GET_CODE (op) == SCRATCH
|| (GET_CODE (op) == REG
- && REGNO (op) < FIRST_PSEUDO_REGISTER));
+ && (REGNO (op) < FIRST_PSEUDO_REGISTER
+ || (reg_renumber
&& reg_renumber[REGNO (op)] < FIRST_PSEUDO_REGISTER)));
}
>
> Also num_freedom was too large for wide pseudos, which made some
> java-files non colorable. (java is notoriously vulnerable to slight
> breakage with the handling of multi-hardreg pseudos. A result of the
> heavy use of DImode)
>
> There are some regressions with C and C++ compared to -fnonew-ra. I now
> test again with deactivated pre-reload, to isolate the causes a little
> bit). I did not yet test SPEC2000.
I'm also suggest to apply the following patch to config/i386/i386.md
(At end of mail. Current mainline GCC had such changes.)
Denis.
PS: Michael can you help me to understand the following case.
PS: (IMHO: I have a very clean understanding of constraints and constraints
modifiers. I have done one port from scratch and optimize two
another ports.) - but may be I'm not so smart. :-(
While debug a new register allocator I have founded a strange thing in
i386 port.
(define_insn "fix_truncdi_nomemory"
[(set (match_operand:DI 0 "nonimmediate_operand" "=m,?r")
(fix:DI (match_operand 1 "register_operand" "f,f")))
----------------------------^^^^
(use (match_operand:HI 2 "memory_operand" "m,m"))
(use (match_operand:HI 3 "memory_operand" "m,m"))
(clobber (match_operand:DI 4 "memory_operand" "=m,m"))
(clobber (match_scratch:DF 5 "=&1f,&1f"))]
-----------------------------------^---^
"TARGET_80387 && FLOAT_MODE_P (GET_MODE (operands[1]))
&& (!SSE_FLOAT_MODE_P (GET_MODE (operands[1])) || !TARGET_64BIT)"
"#"
[(set_attr "type" "fistp")])
operand[5] of "fix_truncdi_nomemory" insn have a constraint
'=&1' this seems wrong for me because description of '&' is
-----------Fragment from gcc info --------------------------------------
`&'
Means (in a particular alternative) that this operand is an
"earlyclobber" operand, which is modified before the instruction is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
finished using the input operands. Therefore, this operand may
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
not lie in a register that is used as an input operand or as part
of any memory address.
------------------------------------------------------------------------
IE: operand[1] can be "modified before the instruction is finished
using the input operands" if operand[5] will satisfy "=&1".
It's a bug.
How to understands '=&1' if it's not a bug ?
------------- Promised patch --------------------------------------------
*** i386.md Thu Aug 23 18:41:19 2001
--- ../../../../gcc-new-alloc/gcc/config/i386/i386.md Thu Apr 4 20:57:00 2002
***************
*** 7403,7409 ****
(zero_extend:TI
(match_operand:DI 2 "nonimmediate_operand" "rm")))
(const_int 64))))
! (clobber (match_scratch:DI 3 "=a"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"mul{q}\t%2"
--- 7403,7409 ----
(zero_extend:TI
(match_operand:DI 2 "nonimmediate_operand" "rm")))
(const_int 64))))
! (clobber (match_scratch:DI 3 "=1"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"mul{q}\t%2"
***************
*** 7421,7427 ****
(zero_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32))))
! (clobber (match_scratch:SI 3 "=a"))
(clobber (reg:CC 17))]
""
"mul{l}\t%2"
--- 7421,7427 ----
(zero_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32))))
! (clobber (match_scratch:SI 3 "=1"))
(clobber (reg:CC 17))]
""
"mul{l}\t%2"
***************
*** 7439,7445 ****
(zero_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32)))))
! (clobber (match_scratch:SI 3 "=a"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"mul{l}\t%2"
--- 7439,7445 ----
(zero_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32)))))
! (clobber (match_scratch:SI 3 "=1"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"mul{l}\t%2"
***************
*** 7457,7463 ****
(sign_extend:TI
(match_operand:DI 2 "nonimmediate_operand" "rm")))
(const_int 64))))
! (clobber (match_scratch:DI 3 "=a"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"imul{q}\t%2"
--- 7457,7463 ----
(sign_extend:TI
(match_operand:DI 2 "nonimmediate_operand" "rm")))
(const_int 64))))
! (clobber (match_scratch:DI 3 "=1"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"imul{q}\t%2"
***************
*** 7474,7480 ****
(sign_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32))))
! (clobber (match_scratch:SI 3 "=a"))
(clobber (reg:CC 17))]
""
"imul{l}\t%2"
--- 7474,7480 ----
(sign_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32))))
! (clobber (match_scratch:SI 3 "=1"))
(clobber (reg:CC 17))]
""
"imul{l}\t%2"
***************
*** 7491,7497 ****
(sign_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32)))))
! (clobber (match_scratch:SI 3 "=a"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"imul{l}\t%2"
--- 7491,7497 ----
(sign_extend:DI
(match_operand:SI 2 "nonimmediate_operand" "rm")))
(const_int 32)))))
! (clobber (match_scratch:SI 3 "=1"))
(clobber (reg:CC 17))]
"TARGET_64BIT"
"imul{l}\t%2"
More information about the Gcc-patches
mailing list