[Patch] Ignore Invalid Memory operands in constraint 'X'

[Patch] Ignore Invalid Memory operands in constraint 'X'

[Hurugalawadi, Naveen]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Hi,

The definition of constraint 'X' allows all operands.
`X' - Any operand whatsoever is allowed.
However, invalid memory operands should not be valid input for 'X'.

Please find attached the patch "X_constraint.patch" which ignores 
invalid memory operands in constraint 'X'.

Fixes the ICE gcc.dg/torture/asm-subreg-1.c on aarch64.

Regression Tested on aarch64-elf. No new Regressions.

2012-12-12  Naveen H.S  <Naveen.Hurugalawadi@caviumnetworks.com>

	*recog.c (asm_operand_ok): Ignore invalid memory operands in
	constraint 'X'

Regards,
Naveen

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: X_constraint.patch --]
[-- Type: text/x-patch; name="X_constraint.patch", Size: 451 bytes --]

--- gcc/recog.c	2012-12-11 16:12:21.896002274 +0530
+++ gcc/recog.c	2012-12-11 16:38:34.004002088 +0530
@@ -1794,7 +1794,12 @@ asm_operand_ok (rtx op, const char *cons
 	  break;
 
 	case 'X':
-	  result = 1;
+	  /* Match any operands except for invalid memory operands.  */
+	  if (! (MEM_P (op)
+		 && ! memory_address_addr_space_p (GET_MODE (op), 
+						   XEXP (op, 0),
+						   MEM_ADDR_SPACE (op))))
+	    result = 1;
 	  break;
 
 	case 'g':

Re: [Patch] Ignore Invalid Memory operands in constraint 'X'

[Ulrich Weigand]

Naveen Hurugalawadi wrote:

> The definition of constraint 'X' allows all operands.
> `X' - Any operand whatsoever is allowed.
> However, invalid memory operands should not be valid input for 'X'.
> 
> Please find attached the patch "X_constraint.patch" which ignores=20
> invalid memory operands in constraint 'X'.

I don't think this is correct.  The internals documentation says:
"Any operand whatsoever is allowed, even if it does not satisfy
@code{general_operand}."

I've seen "X" constraints used in inline assembly where this is
indeed intended.  The point of an "X" constraint is usually to
mark the assembly statement as having a data dependency on the
operand, without actually directly refering to operand (e.g.
because it is acessed implicitly/indirectly).

If the compiler were to reject certain forms of memory operands,
it would have to generate extra code (e.g. reloading an address);
but because "X" operands are not actually refered to by the
assembler code, any such preparatory code would be unnecessary.

[ The only operand forms that ought to be rejected even for "X"
are those that imply side-effects like pre-increment. ]

> Fixes the ICE gcc.dg/torture/asm-subreg-1.c on aarch64.

Clearly the compiler shouldn't crash either, but I guess it
really ought to be possible to fix this problem elsewhere.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com