Patch for h8300 port

Richard Henderson rth@cygnus.com
Fri Oct 6 15:44:00 GMT 2000


On Fri, Oct 06, 2000 at 05:11:53PM -0400, Will Cohen wrote:
> A problem was found that the h8300 compiler due to the compiler
> incorrectly estimating the number of bytes required for some
> instruction sequences.  Due to the compiler's low estimate of the
> number of bytes, the compiler used a branch that could not jump the
> required distance.

I don't quite understand what was wrong.  It appears that each
of the patterns that you changed did in fact properly indicate
that they require 2 or 4 bytes depending on the operands.  I
would like to know what the actual problem is before this goes
much further.

That said, I also see that someone appears to be trying to do
reload's job in the backend, and pretend that these extension
instructions take arguments that they don't.  Perhaps this
resulted in smaller code in some generation of the compiler,
but it seems dodgy in any case.

Once we deal with the correctness problem, there are a few
changes required in your patch:

>   (define_insn ""
> !   [(set (match_operand:HI 0 "register_operand" "=r")
> ! 	(sign_extend:HI (match_operand:QI 1 "general_operand_src" "0")))]
>     "TARGET_H8300H || TARGET_H8300S"
>     "@
> !   exts.w	%T0"
> !   [(set_attr "length" "2")
> !    (set_attr "cc" "set_znv")])

You've reduced the number of alternatives to 1, which
means that you should no longer use the @ format for
the output template.  So just write "exts.w %T0".

The input operand has a matching constraint on the
output operand.  That implies that the input operand
should be using the same predicate.  I.e. use

  (sign_extend:HI (match_operand:QI 1 "register_operand" "0"))



r~


More information about the Gcc-patches mailing list