Marc Glisse <marc.gli...@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
