On Tue, 1 Aug 2023 at 05:20, Jeff Law <jeffreya...@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
Thanks, Prathamesh > > Thanks, > jeff
