[PATCH] Do not allow non-allocatable registers in scratch_operand

Jeff Law law@redhat.com
Fri Sep 19 05:54:00 GMT 2014

On 09/15/14 18:58, Segher Boessenkool wrote:
> Currently, scratch_operand allows all hard registers, also those that
> cannot be allocated and are only generated explicitly by the backend.
> This causes problems.  Consider the case where combine combines
> instructions A and B, where B clobbers such a non-allocatable hard reg X,
> into an instruction C that has a clobber of a match_scratch.  Concretely
> for example:
> A is  (set (reg:SI 98) (eq:SI ...))
> B is  (parallel [(set (reg:SI 99) (minus (const_int 1) (reg:SI 98)))
>                   (clobber (reg:SI CA_REGNO))])
> so that combine tries an insn C
> (parallel [(set (reg:SI 99) (ne:SI ...))
>             (clobber (reg:SI CA_REGNO))])
> which matches the pattern
> (parallel [(set (match_operand:SI 0 "..." "=r") (ne:SI ...))
>             (clobber (match_scratch:SI 3 "=r"))])
> which is not going to work; it is not a valid insn.  (In my testcase,
> reload eventually replaces CA_REGNO with a GPR that is not dead.  Oops.)
> Combine shouldn't keep the original clobbers.  But also, scratch_operand
> should not allow non-allocatable registers, since that can never work.
> This patch does the latter.
> Bootstrapped and regression checked on powerpc64-linux, with options
> -m32,-m32/-mpowerpc64,-m64,-m64/-mlra.  No regressions, and testcase
> fixed (the testcase is forall_4.f90, it requires some backend patches
> to fail).
> Is this okay for mainline?
> Segher
> 2014-09-15  Segher Boessenkool  <segher@kernel.crashing.org>
> 	* recog.c (scratch_operand): Do not simply allow all hard registers:
> 	only allow those that are allocatable.
Shouldn't you be testing if the register is fixed rather than its class? 
  Or maybe both?


More information about the Gcc-patches mailing list