On Wed, 12 Oct 2016, Marc Glisse wrote: > On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote: > > > I was having a look at PR71636 and added the following pattern to match.pd: > > x & ((1U << b) - 1) -> x & ~(~0U << b) > > However the transform is useful only if the target supports "andnot" > > instruction. > > rth was selling the transformation as a canonicalization, which is beneficial > when there is an andnot instruction, and neutral otherwise, so it could be > done always.
Well, its three instructions to three instructions and a more expensive constant(?). ~0U might not be available as immediate for the shift instruction and 1U << b might be available as a bit-set instruction ... (vs. the andnot). So yes, we might decide to canonicalize to andnot (and decide that three binary to two binary and one unary op is "better"). So no excuse to explore the target specific .pd fragment idea ... :/ Richard. > > As pointed out by Marc in PR for -march=core2, lhs generates worse > > code than rhs, > > so we shouldn't do the transform if target doesn't support andnot insn. > > (perhaps we could do the reverse transform for target not supporting > > andnot?) > > Rereading my comment in the PR, I pointed out that instead of being neutral, > the transformation was very slightly detrimental in one case (one extra mov) > because of a RA issue. That doesn't mean we should avoid the transformation, > just that we should fix the RA issue (by the way, if you have time to file a > separate PR for the RA issue, that would be great, otherwise I'll try to do it > at some point...). > > > However it seems andnot isn't a standard pattern name, so am not sure how to > > check if target supports andnot insn ?
