On 13/11/14 22:44, Sandra Loosemore wrote: > On 11/13/2014 10:47 AM, Andrew Pinski wrote: >> On Thu, Nov 13, 2014 at 9:42 AM, Sandra Loosemore >> <san...@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 >>>>> <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. >>> >>> 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? > > I could give that a shot, but it seems unlikely that I will be able to > complete the patch rewrite and testing before we are in Stage 3. If I > have something ready next week, will it be too late for consideration in > GCC 5? >
You're following up on a previously submitted patch and you're not rewriting large chunks of the compiler. I don't think this is really that complicated so I'd be surprised if anyone strongly objected because it wasn't in final form before the end of stage1. I would recommend you try to get it at least re-submitted before the end of the year, though. R.
