This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Simplify a VEC_SELECT fed by its own inverse
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Richard Henderson <rth at redhat dot com>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, ebotcazou at libertysurf dot fr
- Date: Tue, 22 Apr 2014 09:24:51 +0100
- Subject: Re: [PATCH] Simplify a VEC_SELECT fed by its own inverse
- Authentication-results: sourceware.org; auth=none
- References: <1398088880 dot 19378 dot 28 dot camel at gnopaine> <alpine dot DEB dot 2 dot 10 dot 1404211826001 dot 3716 at laptop-mg dot saclay dot inria dot fr> <1398111582 dot 659 dot 3 dot camel at gnopaine> <5355842F dot 3070801 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1404220848050 dot 3704 at laptop-mg dot saclay dot inria dot fr>
Marc Glisse <marc.glisse@inria.fr> writes:
> On Mon, 21 Apr 2014, Richard Henderson wrote:
>
>> On 04/21/2014 01:19 PM, Bill Schmidt wrote:
>>> + if (GET_CODE (trueop0) == VEC_SELECT
>>> + && GET_MODE (XEXP (trueop0, 0)) == mode)
>>> + {
>>> + rtx op0_subop1 = XEXP (trueop0, 1);
>>> + gcc_assert (GET_CODE (op0_subop1) == PARALLEL);
>>> + gcc_assert (XVECLEN (trueop1, 0) == GET_MODE_NUNITS (mode));
>>> +
>>> + /* Apply the outer ordering vector to the inner one. (The inner
>>> + ordering vector is expressly permitted to be of a different
>>> + length than the outer one.) If the result is { 0, 1, ..., n-1 }
>>> + then the two VEC_SELECTs cancel. */
>>> + for (int i = 0; i < XVECLEN (trueop1, 0); ++i)
>>> + {
>>> + rtx x = XVECEXP (trueop1, 0, i);
>>> + gcc_assert (CONST_INT_P (x));
>>> + rtx y = XVECEXP (op0_subop1, 0, INTVAL (x));
>>> + gcc_assert (CONST_INT_P (y));
>>
>> In two places you're asserting that you've got a constant permutation. Surely
>> there should be a non-assertion check and graceful exit for either
>> select to be
>> a variable permutation.
>
> Note that in the case where trueop0 is a CONST_VECTOR, we already check
> each element of trueop1:
>
> gcc_assert (CONST_INT_P (x));
>
> In the case where the result is a scalar, we also have:
>
> gcc_assert (CONST_INT_P (XVECEXP (trueop1, 0, 0)));
>
> so we will have other issues if something ever creates a variable
> vec_select. Not that a graceful exit will hurt of course.
I realise this isn't the point, but maybe we should go easy on this kind
of gcc_assert. Using INTVAL is itself an assertion that you have a
CONST_INT. Adding gcc_asserts on top (and so forcing the assert even
in release compilers) kind-of subverts the --enable-checking option.
Thanks,
Richard