This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Validity of SUBREG+AND-imm transformations
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: Jeff Law <law at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 07 Mar 2016 10:44:22 +0000
- Subject: Re: Validity of SUBREG+AND-imm transformations
- Authentication-results: sourceware.org; auth=none
- References: <56D055C6 dot 6040800 at foss dot arm dot com> <56D0C2A1 dot 1070501 at redhat dot com> <56D422AC dot 2000703 at foss dot arm dot com> <20160304115946 dot GA20650 at gate dot crashing dot org> <56D99E93 dot 70209 at foss dot arm dot com> <56D9A035 dot 2010902 at foss dot arm dot com> <54FB3F2C-EEE0-49E7-BFE5-BF17209B449C at gmail dot com> <56D9B627 dot 2040807 at redhat dot com> <56D9B8E9 dot 4050802 at foss dot arm dot com> <56DA742C dot 1050602 at redhat dot com>
On 05/03/16 05:52, Jeff Law wrote:
On 03/04/2016 09:33 AM, Kyrill Tkachov wrote:
On 04/03/16 16:21, Jeff Law wrote:
On 03/04/2016 08:05 AM, Richard Biener wrote:
does that mean that the shift amount should be DImode?
Seems like a more flexible approach would be for the midend to be able
to handle these things...
Or macroize for all integer modes?
That's probably worth exploring. I wouldn't be at all surprised if it
that turns out to be better than any individual mode, not just for
arm & aarch64, but would help a variety of targets.
What do you mean by 'macroize' here? Do you mean use iterators to create
multple variants of patterns with different
modes on the shift amount?
I believe we'd still run into the issue at
https://gcc.gnu.org/ml/gcc/2016-03/msg00036.html.
We might, but I would expect the the number of incidences to be fewer.
Essentially we're giving the compiler multiple options when it comes to representation of the shift amount -- allowing the compiler (combine in particular) to use the shift amount in whatever mode is most natural. ie, if the count is
sitting in a QI, HI, SI or possibly even a DI register, then it can be used as-is. No subregs, no zero/sign extensions, or and-imm masking.
The RTL documentation for ASHIFT and friends says that the shift amount must be:
"a fixed-point mode or be a constant with mode @code{VOIDmode}; which
mode is determined by the mode called for in the machine description
entry for the left-shift instruction". For example, on the VAX, the mode
of @var{c} is @code{QImode} regardless of @var{m}.
From what I understand the "ashl" standard name should expand to an ASHIFT with a particular mode for the shift amount.
Currently that's QImode for aarch64.
So whenever combine tries to propagate anything into the shift amount it has to force it into QImode.
I don't see how specifying multiple matching patterns for different modes will help as combine propagates
the and-immediate operation into the shift amounts, creates the awkward subreg and tries to match that.
It won't try different modes on the shift amount to help matching (and from previous discussions I understand
that's not the direction we want combine to take).
I've filed PR 70119 to track this down easier (sourceware archives cut of the thread across months :( )
with example code.
Thanks for the ideas,
Kyrill
jeff