This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Validity of SUBREG+AND-imm transformations

On March 4, 2016 3:48:21 PM GMT+01:00, Kyrill Tkachov <> wrote:
>On 04/03/16 14:41, Kyrill Tkachov wrote:
>> 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")
>>>>      (ashift:SI
>>>>        (match_operand:SI 1 "register_operand" "r")
>>>>        (and:QI
>>>>          (match_operand:QI 2 "register_operand" "r")
>>>>          (match_operand:QI 3 "const_int_operand" "n"))))]
>>>> where operands[3] is 31 for SImode. The 'and' expression has to be
>>>> 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
>> would have to dig in the dumps) but it also widens a few memory
>> i.e. we'll now be loading a 32-bit value from memory instead of a
>> Overall it could be a better approach, though it would be a larger
>> and would need more investigation of potential side effects.
>Although there are case where we hit the same problem:
>unsigned long
>f3 (unsigned long bit_addr)
>   unsigned long bitnumb = bit_addr & 63;
>   return (1L << bitnumb);
>combine will try to match:
>(set (reg:DI 78)
>     (ashift:DI (reg:DI 80)
>         (subreg:SI (and:DI (reg:DI 0 x0 [ bit_addr ])
>                 (const_int 63 [0x3f])) 0)))
>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?


>> Thanks,
>> Kyrill
>>> Segher

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]