This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Eric Botcazou <ebotcazou at adacore dot com>, Bernd Schmidt <bschmidt at redhat dot com>, Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 14 Apr 2017 15:15:53 +0100
- Subject: Re: [PATCH] Fix simplify-rtx.c ICE with vector float (not (neg)) (PR rtl-optimization/80385)
- Authentication-results: sourceware.org; auth=none
- References: <20170411112043.GO1809@tucnak>
Jakub Jelinek <jakub@redhat.com> writes:
> Hi!
>
> The x86 intrinsics allow andnot on MODE_VECTOR_FLOAT modes, but
> such modes have NULL CONSTM1_RTX and are not appropriate for the
> transformation anyway.
>
> The following patch fixes that, ok if bootstrap/regtest passes?
> Or would you prefer to replace the
> && CONSTM1_RTX (mode)
> check with e.g.
> && (MODE_CLASS (mode) == MODE_INT
> || MODE_CLASS (mode) == MODE_VECTOR_INT)
> (dunno if we want to handle that way also partial int modes or not,
> no experience with those)?
> The transformation relies on 2's complement, so certainly doesn't apply
> to floating modes (scalar or vector), but even MODE_COMPLEX_INT doesn't
> have CONSTM1_RTX.
Is it valid to have (not: ...) of a floating-point mode? I thought
it had to have an integer mode.
FWIW, in the SVE patches, we deliberately used unspecs for floating-point
logic to avoid this.
Thanks,
Richard