This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: how to check if target supports andnot instruction ?
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 12 Oct 2016 11:07:11 +0200 (CEST)
- Subject: Re: how to check if target supports andnot instruction ?
- Authentication-results: sourceware.org; auth=none
- References: <CAAgBjMkJfLh=OsbkwHt4fw=_kazop2rZ2NfWoor62aHSSj=aPg@mail.gmail.com>
- Reply-to: gcc at gcc dot gnu dot org
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.
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 ?
--
Marc Glisse