This is the mail archive of the
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: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 04 Mar 2016 14:41:23 +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>
On 04/03/16 11:59, Segher Boessenkool wrote:
On Mon, Feb 29, 2016 at 10:51:24AM +0000, Kyrill Tkachov wrote:
So I'm trying to create a define_insn to match something like:
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operand:SI 1 "register_operand" "r")
(match_operand:QI 2 "register_operand" "r")
(match_operand:QI 3 "const_int_operand" "n"))))]
where operands is 31 for SImode. The 'and' expression has to be in
QImode because our shift expanders
expand the shift amount to QImode.
Is there any reason for that? Why not SImode?
It's been that way since the beginning. I don't know the reason.
I tried changing to SImode. It requires a lot mechanical changes to
all the shift+arithmetic patterns, but it does work.
It catches a few more cases that my original approach (not sure why yet,
would have to dig in the dumps) but it also widens a few memory accesses
i.e. we'll now be loading a 32-bit value from memory instead of a byte.
Overall it could be a better approach, though it would be a larger patch
and would need more investigation of potential side effects.