On 13/11/14 17:42, Sandra Loosemore wrote:
> On 11/13/2014 10:27 AM, Richard Earnshaw wrote:
>> On 13/11/14 17:05, Ramana Radhakrishnan wrote:
>>> On Thu, Nov 13, 2014 at 4:55 PM, Sandra Loosemore
>>> <san...@codesourcery.com> wrote:
>>>> This patch to the AArch64 back end adds a couple of additional bics
>>>> patterns
>>>> to match code of the form
>>>>
>>>> if ((x & y) == x) ...;
>>>>
>>>> This is testing whether the bits set in x are a subset of the bits set in
>>>> y;
>>>> or, that no bits in x are set that are not set in y. So, it is equivalent
>>>> to
>>>>
>>>> if ((x & ~y) == 0) ...;
>>>>
>>>> Presently this generates code like
>>>> and x21, x21, x20
>>>> cmp x21, x20
>>>> b.eq c0 <main+0xc0>
>>>>
>>>> and this patch allows it to be written more concisely as:
>>>> bics x21, x20, x21
>>>> b.eq c0 <main+0xc0>
>>>>
>>>> Since the bics instruction sets the condition codes itself, no explicit
>>>> comparison is required and the result of the bics computation can be
>>>> discarded.
>>>>
>>>> Regression-tested on aarch64-linux-gnu. OK to commit?
>>>
>>> Is this not a duplicate of
>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00943.html ?
>>>
>>>
>> I don't think so. However, I think it is something that should be
>> caught in generic simplification code
>>
>> ie map ((a & b) == b) ==> ((~a & b) == 0), etc
>>
>> Bit-clear operations are not that uncommon. Furthermore, A may be a
>> constant.
>
> Alex posted his patch when I already had Chris's in my regression test
> queue, but I've just confirmed that it does not fix the test case I
> included.
Alex's patch is adding a proper pattern for the BICS instruction. I
wouldn't expect it to directly achieve what you are trying to do - but I
do think the compiler should transform what you have into the form that
Alex has just added the patterns for.
>
> I already thought a little about making this a generic simplification,
> but it seemed to me like it was only useful on targets that have a
> bit-clear instruction that happens to set condition codes, and that it
> would pessimize code on targets that don't have a bit-clear instruction
> at all (by inserting the extra complement operation). So to me it
> seemed reasonable to do it in the back end.
I doubt that. I'd be surprised if any target had a direct ((A & B) ==
A) type comparison, so all you're doing is canonicalizing something that
no target is likely to have into something some targets have. And
ulitimately, if the pattern doesn't match, combine will just undo all
the changes. Furthermore, as I previously said, if B is a constant then
you're going to get a real optimization for that case that is widely
applicable. Eg
A & ~1 == A
will simplify into
A & 1 == 0
Many targets will have a flag-setting AND operation.
R.
