This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, aarch64] additional bics patterns


On Thu, Nov 13, 2014 at 9:42 AM, Sandra Loosemore
<sandra@codesourcery.com> 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
>>> <sandra@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.
>
> 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.

But can't you do this in simplify-rtx.c and allow for the cost model
to do the correct thing?

Thanks,
Andrew

>
> -Sandra
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]