public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
To: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>,
		GCC Patches <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: [RFC][PR88838][SVE] Use 32-bit WHILELO in LP64 mode
Date: Thu, 06 Jun 2019 11:40:00 -0000	[thread overview]
Message-ID: <CAELXzTOmwQDfTK1TgTnPX5KSyLH4VP20fftLcsRkfGA0Zk07qw@mail.gmail.com> (raw)
In-Reply-To: <mptpnnrhx99.fsf@arm.com>

Hi Richard,

On Thu, 6 Jun 2019 at 19:35, Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org> writes:
> > Hi Richard,
> >
> > Thanks for the review. Attached is the latest patch.
> >
> > For testcase like cond_arith_1.c, with the patch, gcc ICE in fwprop. I
> > am limiting fwprop in cases like this. Is there a better fix for this?
> > index cf2c9de..2c99285 100644
> > --- a/gcc/fwprop.c
> > +++ b/gcc/fwprop.c
> > @@ -1358,6 +1358,15 @@ forward_propagate_and_simplify (df_ref use,
> > rtx_insn *def_insn, rtx def_set)
> >    else
> >      mode = GET_MODE (*loc);
> >
> > +  /* TODO. We can't get the mode for
> > +     (set (reg:VNx16BI 109)
> > +          (unspec:VNx16BI [
> > +        (reg:SI 131)
> > +        (reg:SI 106)
> > +           ] UNSPEC_WHILE_LO))
> > +     Thus, bailout when it is UNSPEC and MODEs are not compatible.  */
> > +  if (GET_MODE_CLASS (mode) != GET_MODE_CLASS (GET_MODE (reg)))
> > +    return false;
> >    new_rtx = propagate_rtx (*loc, mode, reg, src,
> >                   optimize_bb_for_speed_p (BLOCK_FOR_INSN (use_insn)));
>
> What specifically goes wrong?  The unspec above isn't that unusual --
> many unspecs have different modes from their inputs.

cond_arith_1.c:38:1: internal compiler error: in paradoxical_subreg_p,
at rtl.h:3130
0x135f1d3 paradoxical_subreg_p(machine_mode, machine_mode)
        ../../88838/gcc/rtl.h:3130
0x135f1d3 propagate_rtx
        ../../88838/gcc/fwprop.c:683
0x135f4a3 forward_propagate_and_simplify
        ../../88838/gcc/fwprop.c:1371
0x135f4a3 forward_propagate_into
        ../../88838/gcc/fwprop.c:1430
0x135fdcb fwprop
        ../../88838/gcc/fwprop.c:1519
0x135fdcb execute
        ../../88838/gcc/fwprop.c:1550
Please submit a full bug report,
with preprocessed source if appropriate.


in forward_propagate_and_simplify

use_set:
(set (reg:VNx16BI 96 [ loop_mask_52 ])
    (unspec:VNx16BI [
            (reg:SI 92 [ _3 ])
            (reg:SI 95 [ niters.36 ])
        ] UNSPEC_WHILE_LO))

reg:
(reg:SI 92 [ _3 ])

*loc:
(unspec:VNx16BI [
        (reg:SI 92 [ _3 ])
        (reg:SI 95 [ niters.36 ])
    ] UNSPEC_WHILE_LO)

src:
(subreg:SI (reg:DI 136 [ ivtmp_101 ]) 0)

use_insn:
(insn 87 86 88 4 (parallel [
            (set (reg:VNx16BI 96 [ loop_mask_52 ])
                (unspec:VNx16BI [
                        (reg:SI 92 [ _3 ])
                        (reg:SI 95 [ niters.36 ])
                    ] UNSPEC_WHILE_LO))
            (clobber (reg:CC 66 cc))
        ]) 4255 {while_ultsivnx16bi}
     (expr_list:REG_UNUSED (reg:CC 66 cc)
        (nil)))

I think we calculate the mode to be VNx16BI which is wrong?
because of which in propgate_rtx,   !paradoxical_subreg_p (mode,
GET_MODE (SUBREG_REG (new_rtx)))))  ICE

Thanks,
Kugan

>
> Thanks,
> Richard

  reply	other threads:[~2019-06-06 11:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22  2:09 Kugan Vivekanandarajah
2019-05-25  9:41 ` Richard Sandiford
2019-05-28  2:50   ` Kugan Vivekanandarajah
2019-05-28 11:21     ` Richard Sandiford
2019-05-31  7:24       ` Kugan Vivekanandarajah
2019-05-31  9:44         ` Richard Sandiford
2019-06-03  3:24           ` Kugan Vivekanandarajah
2019-06-03  9:08             ` Richard Sandiford
2019-06-06  1:28               ` Kugan Vivekanandarajah
2019-06-06  9:35                 ` Richard Sandiford
2019-06-06 11:40                   ` Kugan Vivekanandarajah [this message]
2019-06-06 12:07                     ` Richard Sandiford
2019-06-06 12:19                       ` Kugan Vivekanandarajah
2019-06-06 12:33                         ` Richard Sandiford
2019-06-07  0:01                           ` Jeff Law
2019-06-07  7:41                             ` Richard Sandiford

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAELXzTOmwQDfTK1TgTnPX5KSyLH4VP20fftLcsRkfGA0Zk07qw@mail.gmail.com \
    --to=kugan.vivekanandarajah@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).