This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] SHIFT_COUNT_TRUNCATED and shift_truncation_mask
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Uros Bizjak <ubizjak at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jeff Law <law at redhat dot com>, Robin Dapp <rdapp at linux dot ibm dot com>
- Date: Fri, 10 May 2019 09:34:57 -0500
- Subject: Re: [RFC] SHIFT_COUNT_TRUNCATED and shift_truncation_mask
- References: <CAFULd4Y5xmJaHO=T4fuZU3sSqsx49SdsvzXDNdpFBdjSS_dFXQ@mail.gmail.com> <CAFiYyc2X9dJq4_NwY=JsaJnOrua7SfH23Pu7HDmZ3V6O3ek+Kg@mail.gmail.com> <CAFULd4ZP3yk0eVhvXah0jQK3AY-yohXxGdEq-UqT7idL2qFJ+g@mail.gmail.com> <CAFiYyc2jOkDAod2UdEjqMsB=Uo9UxRiUN5YGshvBB6HSSC9MKA@mail.gmail.com>
On Fri, May 10, 2019 at 09:42:47AM +0200, Richard Biener wrote:
> On Fri, May 10, 2019 at 9:25 AM Uros Bizjak <ubizjak@gmail.com> wrote:
> > > But IL semantic differences based on mode is even worse. What happens
> > > if STV then substitues a vector register/op but you previously optimized
> > > with the assumption the count would be truncated since the shift was SImode?
What is STV?
> But that's more a combine limitation than a reason going for the
> "hidden" IL semantic change. But yes, if the and is used by
> non-masking insns then it's likely cheap enough to retain it.
>
> If the masking were always in place (combined with the shift
> if a suitable insn exists) then STV handling should be possible,
> it just would need to split the insn to do the masking and then the shift
> (of course that might not be very profitable).
Why does the pattern with masking split? It could just be a define_insn.
Combine will try to get rid of the masking, to simplify the RTL. Going in the
other direction is probably not profitable :-/
Segher