This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Disable -fweb on 68hc11

Hash: SHA1

Kazu Hirata wrote:
| Hi Stephane,
|>(define_insn "*ashlsi3_const"
|>~  [(set (match_operand:SI 0 "register_operand" "+D")
|>	(ashift:SI (match_dup 0)
|>	           (match_operand:HI 1 "const_int_operand" "")))
|>~   (clobber (match_scratch:HI 2 "=y"))]
| I thought this should be something like
| [(set (match_operand:SI 0 "register_operand" "=D")
|       (ashift:SI (match_operand:SI 1 "register_operand" "0")
| 		 (match_operand:HI 2 "const_int_operand" "")))
|  (clobber (match_scratch:HI 3 "=y"))]
| It is the register allocator that actually matches operands[0] and
| operands[1], not by using match_dup.
| Kazu Hirata

My point is to avoid this for this particular insn.

If you write this, you create one more operand and increase the reload:
~  - the input operand 1 must be reloaded (from one source)
~  - the output operand 0 must be reloaded (to a different dest)

The input and ouput reloads may require address registers. Since they
are different, they may require conflicting registers.  Then, this conflicts
with the 3 registers with are required by the insn (2 are used for the 32-bit
and 1 is used for the scratch; there is no free register).

By using a match_dup I have the guarantee that the operand 0 and 1 have
the same reloads and hence reduce the number of reload registers.

For the 16-bit operations, I use the "0" constraint since this issue is
not there (at least reload is less stressed...).


Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]