Re: [Patch ARM] Fix PR71778

[Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>]

Hi James,

On 12/06/17 14:57, James Greenhalgh wrote:
> Hi,
>
> PR71778 is an ICE when you pass a non-constant argument to an intrinsic
> which requires a constant.
>
> This ICE was introduced after we rewrote some of the builtin handling for
> Neon intrinsics, the issue is that after throwing an error in
> arm_expand_builtin_args, we return const0_rtx to indicate the expand
> has failed
>
>        if (!(*insn_data[icode].operand[opno].predicate)
> 	  (op[argc], mode[argc]))
> 	{
> 	  error ("%Kargument %d must be a constant immediate",
> 		 exp, argc + 1);
> 	  return const0_rtx;
> 	}
>
> At this point we're safely in to invalid code, but the mid-end continues
> trying to resolve the assignment, with const0_rtx on the right-hand
> side. That gets in to trouble in movv2di, which sees the constant and
> tries to expand through neon_make_constant, which doesn't expect to see
> a const0_rtx in the assignment (it wants a vector), and we hit a
> gcc_unreachable () and take the ICE.

That movv2di expander is the one in vec-common.md that ends up calling
neon_make_constant. I wonder why const0_rtx passed its predicate check
(that would require a V2DImode vector of zeroes rather than a const0_rtx).
Perhaps the midend code at this point doesn't check the operand predicate.

In the builtin expansion code that you quoted I wonder wonder if we could fail
more gracefully by returning CONST0_RTX (mode[argc]) to match the expected
mode of the operand (we've already emitted an error, so we shouldn't care
what RTL we emit as long as it doesn't cause an ICE).

> There are a few moving parts in the back end, so it isn't clear to me that
> the fix I've come up with is 100% in the right place. AArch64 doesn't
> bother with a similar construct, expanding straight to a mov with whatever
> you've given it, so I don't see a right place over there.
>
> The change is defensible, but I don't really know the ARM back end.
>
> Bootstrapped on arm-none-linux-gnueabihf.
>
> OK?
>
> Thanks,
> James
>
> ---
> gcc/
>
> 2017-06-12  James Greenhalgh  <james.greenhalgh@arm.com>
>
> 	PR target/71778
> 	* config/arm/arm.c (neon_make_constant): Return const0_rtx for
> 	const0_rtx input.
>
> gcc/testsuite/
>
> 2017-06-12  James Greenhalgh  <james.greenhalgh@arm.com>
>
> 	PR target/71778
> 	* gcc.target/arm/pr71778.c: New.
>

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index e503891..b8d59c6 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -12124,6 +12124,11 @@ neon_make_constant (rtx vals)
        if (n_const == n_elts)
  	const_vec = gen_rtx_CONST_VECTOR (mode, XVEC (vals, 0));
      }
+  else if (vals == const0_rtx)
+    /* Something invalid, perhaps from expanding an intrinsic
+       which requires a constant argument, where a variable argument
+       was passed.  */
+     return const0_rtx;
    else
      gcc_unreachable ();

I'm not a fan of this as the function has a precondition that its argument is a PARALLEL or a CONST_VECTOR
and special-casing const0_rtx breaks that. I'd rather we tried fixing this closer to the error source.
Can you try the suggestion above instead please?

Thanks,
Kyrill