This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Remove redundant AND from count reduction loop
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 24 Jun 2015 12:10:18 +0100
- Subject: Re: Remove redundant AND from count reduction loop
- Authentication-results: sourceware.org; auth=none
- References: <87pp4m8mkp dot fsf at e105548-lin dot cambridge dot arm dot com> <alpine dot DEB dot 2 dot 20 dot 1506232307180 dot 1715 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0F3YqAjr2+EMf8STUBrVN+bE3aYpC+1nnstSaf2oiaDg at mail dot gmail dot com> <87egl1sa2p dot fsf at e105548-lin dot cambridge dot arm dot com> <CAFiYyc0_JiQSZ=M1NqZAaDgh6kYy_EXtpZp9cd2NJOtTG46ang at mail dot gmail dot com>
Richard Biener <richard.guenther@gmail.com> writes:
>>> I'm fine with using tree_nop_conversion_p for now.
>>
>> I like the suggestion about checking TYPE_VECTOR_SUBPARTS and the element
>> mode. How about:
>>
>> (if (VECTOR_INTEGER_TYPE_P (type)
>> && TYPE_VECTOR_SUBPARTS (type) == TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))
>> && (TYPE_MODE (TREE_TYPE (type))
>> == TYPE_MODE (TREE_TYPE (TREE_TYPE (@0)))))
>>
>> (But is it really OK to be adding more mode-based compatibility checks?
>> I thought you were hoping to move away from modes in the middle end.)
>
> The TYPE_MODE check makes the VECTOR_INTEGER_TYPE_P check redundant
> (the type of a comparison is always a signed vector integer type).
OK, will just use VECTOR_TYPE_P then.
>>>>> +/* We could instead convert all instances of the vec_cond to negate,
>>>>> + but that isn't necessarily a win on its own. */
>>>
>>> so p ? 1 : 0 -> -p? Why isn't that a win on its own? It looks more compact
>>> at least ;) It would also simplify the patterns below.
>>
>> In the past I've dealt with processors where arithmetic wasn't handled
>> as efficiently as logical ops. Seems like an especial risk for 64-bit
>> elements, from a quick scan of the i386 scheduling models.
>
> But then expansion could undo this ...
So do the inverse fold and convert (neg (cond)) to (vec_cond cond 1 0)?
Is there precendent for doing that kind of thing?
>> I also realised later that:
>>
>> /* Vector comparisons are defined to produce all-one or all-zero results. */
>> (simplify
>> (vec_cond @0 integer_all_onesp@1 integer_zerop@2)
>> (if (tree_nop_conversion_p (type, TREE_TYPE (@0)))
>> (convert @0)))
>>
>> is redundant with some fold-const.c code.
>
> If so then you should remove the fold-const.c at the time you add the pattern.
Can I just drop that part of the patch instead? The fold-const.c
code handles COND_EXPR and VEC_COND_EXPR analogously, so I'd have
to move COND_EXPR at the same time. And then the natural follow-on
would be: why not move the other COND_EXPR and VEC_COND_EXPR folds too? :-)
> Note that ISTR code performing exactly the opposite transform in
> fold-const.c ...
That's another reason why I'm worried about just doing the (negate ...)
thing without knowing whether the negate can be folded into anything else.
Thanks,
Richard