From: Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>
To: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
Cc: Jeff Law <jeffreyalaw@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v2] combine: Narrow comparison of memory and constant
Date: Tue, 1 Aug 2023 11:36:07 +0200 [thread overview]
Message-ID: <ZMjSB1vyo6xUw8Hh@li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com> (raw)
In-Reply-To: <CAAgBjMkT80ERBkN0_N0v20DmODa_WD-rBHbAyRbjNRNddsykOg@mail.gmail.com>
On Tue, Aug 01, 2023 at 01:52:16PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 1 Aug 2023 at 05:20, Jeff Law <jeffreyalaw@gmail.com> wrote:
> >
> >
> >
> > On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Frielinghaus via
> > > Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
> > >>
> > >> Comparisons between memory and constants might be done in a smaller mode
> > >> resulting in smaller constants which might finally end up as immediates
> > >> instead of in the literal pool.
> > >>
> > >> For example, on s390x a non-symmetric comparison like
> > >> x <= 0x3fffffffffffffff
> > >> results in the constant being spilled to the literal pool and an 8 byte
> > >> memory comparison is emitted. Ideally, an equivalent comparison
> > >> x0 <= 0x3f
> > >> where x0 is the most significant byte of x, is emitted where the
> > >> constant is smaller and more likely to materialize as an immediate.
> > >>
> > >> Similarly, comparisons of the form
> > >> x >= 0x4000000000000000
> > >> can be shortened into x0 >= 0x40.
> > >>
> > >> Bootstrapped and regtested on s390x, x64, aarch64, and powerpc64le.
> > >> Note, the new tests show that for the mentioned little-endian targets
> > >> the optimization does not materialize since either the costs of the new
> > >> instructions are higher or they do not match. Still ok for mainline?
> > > Hi Stefan,
> > > Unfortunately this patch (committed in 7cdd0860949c6c3232e6cff1d7ca37bb5234074c)
> > > caused the following ICE on armv8l-unknown-linux-gnu:
> > > during RTL pass: combine
> > > ../../../gcc/libgcc/fixed-bit.c: In function ‘__gnu_saturate1sq’:
> > > ../../../gcc/libgcc/fixed-bit.c:210:1: internal compiler error: in
> > > decompose, at rtl.h:2297
> > > 210 | }
> > > | ^
> > > 0xaa23e3 wi::int_traits<std::pair<rtx_def*, machine_mode>
> > >> ::decompose(long long*, unsigned int, std::pair<rtx_def*,
> > > machine_mode> const&)
> > > ../../gcc/gcc/rtl.h:2297
> > [ ... ]
> > Yea, we're seeing something very similar on nios2-linux-gnu building the
> > kernel.
> >
> > Prathamesh, can you extract the .i file for fixed-bit on armv8 and open
> > a bug for this issue, attaching the .i file as well as the right command
> > line options necessary to reproduce the failure. THat way Stefan can
> > tackle it with a cross compiler.
> Hi Jeff,
> Filed the issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
Hi Prathamesh,
Sorry for the inconvenience. I will have a look at this and thanks for
the small reproducer. I already started to come up with a cross
compiler.
Thanks,
Stefan
>
> Thanks,
> Prathamesh
> >
> > Thanks,
> > jeff
prev parent reply other threads:[~2023-08-01 9:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 7:57 [PATCH] " Stefan Schulze Frielinghaus
2023-06-12 21:29 ` Jeff Law
2023-06-19 14:19 ` Stefan Schulze Frielinghaus
2023-06-19 14:23 ` [PATCH v2] " Stefan Schulze Frielinghaus
2023-07-31 13:26 ` Stefan Schulze Frielinghaus
2023-07-31 13:59 ` Jeff Law
2023-07-31 21:43 ` Prathamesh Kulkarni
2023-07-31 21:46 ` Prathamesh Kulkarni
2023-07-31 23:50 ` Jeff Law
2023-08-01 8:22 ` Prathamesh Kulkarni
2023-08-01 9:36 ` Stefan Schulze Frielinghaus [this message]
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=ZMjSB1vyo6xUw8Hh@li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com \
--to=stefansf@linux.ibm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=prathamesh.kulkarni@linaro.org \
/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).