This is the mail archive of the gcc-patches@gcc.gnu.org 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54589


On Thu, Nov 29, 2018 at 4:09 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Thu, Nov 29, 2018 at 08:13:48PM +0530, Umesh Kalappa wrote:
> > We are able to fix the subjected issue  with the  peephole patterns
> > (target specific) in the md file (attached the patch pr54589.patch).
> > While testing the fix ,we end up with some of the C constructs like
>
> The right thing for this sort of transformations is generally combiner
> and it works for most complex addressing cases.  The reason why it doesn't
> work in this case is that:
> Failed to match this instruction:
> (set (mem:SI (reg:DI 97) [2 *dst_7(D)+0 S4 A32])
>     (vec_select:SI (mem:V4SI (plus:DI (plus:DI (mult:DI (reg:DI 90 [ *src_4(D) ])
>                         (const_int 16 [0x10]))
>                     (reg/f:DI 16 argp))
>                 (const_int 16 [0x10])) [1 p.array S16 A128])
>         (parallel [
>                 (const_int 0 [0])
>             ])))
> Indeed, x86 doesn't have scale 16 addressing mode nor anything higher,
> so the above isn't recognized and combiner only tries
> Failed to match this instruction:
> (set (reg:DI 95)
>     (plus:DI (ashift:DI (reg:DI 90 [ *src_4(D) ])
>             (const_int 4 [0x4]))
>         (reg/f:DI 16 argp)))
> after it, which doesn't help.
>
> For (x + N) << M, replacing it with (x << M) + (N << M) isn't generally
> a win, e.g. the (N << M) constant could be expensive to construct in a
> register, so optimizing that at GIMPLE level is not right, furthermore
> it isn't even visible at GIMPLE level, as it is just part of ARRAY_REF
> addressing (or could be).
>
> Not sure how hard would be to teach combiner to retry for the addressing
> case with the mult/ashift replaced with a register and if successful,
> emit that multiplication/shift as a separate instruction in 3->2 or 4->2
> combination.  Segher?

Maybe a combine splitter can be used here? Please see documentation
from paragraph 17.16 onward:

--quote--
 The insn combiner phase also splits putative insns.  If three insns are
merged into one insn with a complex expression that cannot be matched by
some 'define_insn' pattern, the combiner phase attempts to split the
complex pattern into two insns that are recognized.  Usually it can
break the complex pattern into two patterns by splitting out some
subexpression.  However, in some other cases, such as performing an
addition of a large constant in two insns on a RISC machine, the way to
split the addition into two insns is machine-dependent.

...

--/quote--

Uros.


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