On Tue, Jun 04, 2024 at 09:50:04AM +0200, Richard Biener wrote:
> On Tue, Jun 4, 2024 at 8:52 AM Stefan Schulze Frielinghaus via Gcc
> wrote:
> >
> > Hi all,
> >
> > Is there some sort of guarantee that the unused part of a partial vector has
> > all bits set t
Hi all,
Is there some sort of guarantee that the unused part of a partial vector has
all bits set to zero?
The question came up while implementing an insn for mode V2SF on s390
where only half of the hard register would be utilized. The final
machine instruction, however, would make use of the
https://gcc.gnu.org/g:57e04879389f9c0d5d53f316b468ce1bddbab350
commit r15-787-g57e04879389f9c0d5d53f316b468ce1bddbab350
Author: Stefan Schulze Frielinghaus
Date: Thu May 23 08:43:35 2024 +0200
s390: Implement TARGET_NOCE_CONVERSION_PROFITABLE_P [PR109549]
Consider a NOCE
https://gcc.gnu.org/g:e755f478c24c3e99409936af545ac83d35d27ad9
commit r15-319-ge755f478c24c3e99409936af545ac83d35d27ad9
Author: Stefan Schulze Frielinghaus
Date: Wed May 8 10:48:45 2024 +0200
tree-ssa-loop-prefetch.cc: Honour -fno-unroll-loops
This fixes a couple of tests
https://gcc.gnu.org/g:e1f56c67a82172730c377a96a46e8d75445e6a48
commit r15-274-ge1f56c67a82172730c377a96a46e8d75445e6a48
Author: Stefan Schulze Frielinghaus
Date: Tue May 7 14:12:55 2024 +0200
tree-optimization/110490 - bitcount for narrow modes
Bitcount operations popcount, clz,
https://gcc.gnu.org/g:66f49ccd409c7a3f6eb89dd78e275ab57c983c79
commit r15-102-g66f49ccd409c7a3f6eb89dd78e275ab57c983c79
Author: Stefan Schulze Frielinghaus
Date: Thu May 2 08:43:50 2024 +0200
s390: testsuite: Fix risbg-ll-2.c
Starting with r14-2047-gd0e891406b16dc we see through
https://gcc.gnu.org/g:6c4a745c6910659a75d1881cf3c4128f24b5666f
commit r15-100-g6c4a745c6910659a75d1881cf3c4128f24b5666f
Author: Stefan Schulze Frielinghaus
Date: Thu May 2 08:39:32 2024 +0200
s390: testsuite: Fix zero_bits_compound-1.c
Starting with r12-2731-g96146e61cd7aee we do
Hi all,
while bisecting I recently ran into build errors like
In file included from /devel/gcc/libgcc/../gcc/tsystem.h:101,
from /devel/gcc/libgcc/libgcov.h:42,
from /devel/gcc/libgcc/libgcov-interface.c:26:
/usr/include/stdlib.h:931:6: error: wrong number of
https://gcc.gnu.org/g:3d5699930fe6cfc595e5a920ab36a1bc065be534
commit r14-10090-g3d5699930fe6cfc595e5a920ab36a1bc065be534
Author: Stefan Schulze Frielinghaus
Date: Tue Apr 23 13:29:10 2024 +0200
s390: testsuite: Xfail forwprop-4{0,1}.c
The tests fail on s390 since
https://gcc.gnu.org/g:16aea8c584ea2784a4f5a39352f867506d3441f6
commit r14-10066-g16aea8c584ea2784a4f5a39352f867506d3441f6
Author: Stefan Schulze Frielinghaus
Date: Mon Apr 15 15:28:43 2024 +0200
s390: testsuite: Remove xfail for vpopct{b,h}
Starting with r14-9316-g7890836de20912
https://gcc.gnu.org/g:a76f236e084cbd02e4e3711cdfc3191dc7eeb460
commit r14-9939-ga76f236e084cbd02e4e3711cdfc3191dc7eeb460
Author: Stefan Schulze Frielinghaus
Date: Fri Apr 12 16:54:38 2024 +0200
s390: testsuite: Xfail range-sincos.c and vrp-float-abs-1.c
As mentioned in PR114678
https://gcc.gnu.org/g:67e1433a94f8ca82e2c36b79af44256430c73c38
commit r14-9935-g67e1433a94f8ca82e2c36b79af44256430c73c38
Author: Stefan Schulze Frielinghaus
Date: Fri Apr 12 11:06:24 2024 +0200
analyzer: Bail out on function pointer for -Wanalyzer-allocation-size
On s390
https://gcc.gnu.org/g:b6c8259076a336e8082853ed6dda083c25a465d0
commit r14-9931-gb6c8259076a336e8082853ed6dda083c25a465d0
Author: Stefan Schulze Frielinghaus
Date: Fri Apr 12 09:20:53 2024 +0200
testsuite: Fix loop-interchange-16.c
Prevent loop unrolling of the innermost loop
https://gcc.gnu.org/g:291c46a3f0d0355680f94280e955f4faf1cae6f9
commit r14-9683-g291c46a3f0d0355680f94280e955f4faf1cae6f9
Author: Stefan Schulze Frielinghaus
Date: Wed Mar 27 08:50:47 2024 +0100
testsuite: Fix copy-headers-8.c
For targets where LOGICAL_OP_NON_SHORT_CIRCUIT
https://gcc.gnu.org/g:e0a7233e1d2e617e1913b9873599e7a50bfe1c8f
commit r14-9615-ge0a7233e1d2e617e1913b9873599e7a50bfe1c8f
Author: Stefan Schulze Frielinghaus
Date: Fri Mar 22 11:23:24 2024 +0100
s390: testsuite: Fix backprop-6.c
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/g:d4ad99b0355bce23524aa0ecb5100b987279de96
commit r14-9608-gd4ad99b0355bce23524aa0ecb5100b987279de96
Author: Stefan Schulze Frielinghaus
Date: Fri Mar 22 08:41:39 2024 +0100
s390: testsuite: Fix abs-4.c
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/g:4d049fadc25585e336c06e6b60b592f40ddbcc12
commit r14-9451-g4d049fadc25585e336c06e6b60b592f40ddbcc12
Author: Stefan Schulze Frielinghaus
Date: Wed Mar 13 11:07:03 2024 +0100
s390: Fix TARGET_SECONDARY_RELOAD for non-SYMBOL_REFs
RTX X need not necessarily be a
https://gcc.gnu.org/g:a63fb786f8564880c91a30b99fda6d8a44adf81d
commit r14-9450-ga63fb786f8564880c91a30b99fda6d8a44adf81d
Author: Stefan Schulze Frielinghaus
Date: Wed Mar 13 11:05:08 2024 +0100
s390: Fix tests rosbg_si_srl and rxsbg_si_srl
Starting with r14-2047-gd0e891406b16dc
https://gcc.gnu.org/g:9f2b16ce1efef0648a6d52c1d744735c46e2eec1
commit r14-9449-g9f2b16ce1efef0648a6d52c1d744735c46e2eec1
Author: Stefan Schulze Frielinghaus
Date: Wed Mar 13 11:03:02 2024 +0100
s390: Streamline vector builtins with LLVM
Similar as to s390_lcbb, s390_vll,
https://gcc.gnu.org/g:b59f0c9c5a4838658dd2a1db58ac09d9f3be0f51
commit r14-9448-gb59f0c9c5a4838658dd2a1db58ac09d9f3be0f51
Author: Stefan Schulze Frielinghaus
Date: Wed Mar 13 10:59:02 2024 +0100
s390: Deprecate some vector builtins
According to IBM Open XL C/C++ for z/OS version
On Mon, Aug 28, 2023 at 11:33:37AM +0200, Andreas Krebbel wrote:
> Hi Stefan,
>
> do you really need to introduce a new flag for U64 given that the type of the
> builtin is unsigned long?
In function s390_const_operand_ok the immediate is checked whether it is
valide w.r.t. the flag:
Ping.
On Thu, Aug 24, 2023 at 11:31:32AM +0800, Xi Ruoyao wrote:
> Ping again.
>
> On Fri, 2023-08-18 at 13:04 +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > Ping. Since this fixes bootstrap problem PR110939 for Loongarch I'm
> > pingen this one earli
The second argument of these builtins is an unsigned immediate. For
vec_rli the API allows immediates up to 64 bits whereas the instruction
verll only allows immediates up to 32 bits. Since the shift count
equals the immediate modulo vector element size, truncating those
immediates is fine.
Bootstrapped and regtested on s390. Ok for mainline?
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_signed_flt): Fix
builtin flag.
(s390_vec_unsigned_flt): Ditto.
(s390_vec_revb_flt): Ditto.
(s390_vec_reve_flt): Ditto.
(s390_vclfnhs):
Ping. Since this fixes bootstrap problem PR110939 for Loongarch I'm
pingen this one earlier.
On Thu, Aug 10, 2023 at 03:04:03PM +0200, Stefan Schulze Frielinghaus wrote:
> In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> completely missed the fact that the normal form of
Hi everyone,
I have bootstrapped and regtested the patch below on s390. For the
64-bit target I do not see any changes regarding the testsuite. For the
31-bit target I see the following failures:
FAIL: gcc.dg/vect/no-scevccp-outer-14.c (internal compiler error: in require,
at machmode.h:313)
On Sat, Aug 12, 2023 at 09:04:19AM +0800, Xi Ruoyao wrote:
> On Thu, 2023-08-10 at 15:04 +0200, Stefan Schulze Frielinghaus via Gcc-
> patches wrote:
> > In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
> > completely missed the fact that the normal f
In the former fix in commit 41ef5a34161356817807be3a2e51fbdbe575ae85 I
completely missed the fact that the normal form of a generated constant for a
mode with fewer bits than in HOST_WIDE_INT is a sign extended version of the
actual constant. This even holds true for unsigned constants.
Fixed by
This fixes the rather new tests cmp-mem-const-{1,2,3,4,5,6}.c for sparc.
For -1 and -2 we need at least optimization level 2 on sparc. For the
sake of homogeneity, change all test cases to -O2. For -3 and -4 we do
not end up with a comparison of memory and a constant, and finally for
-5 and -6
Bootstrapped and regtested on s390x. Ok for mainline?
gcc/ChangeLog:
* config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate):
New function which handles bswap patterns for vec_perm_const.
(vectorize_vec_perm_const_1): Call new function.
*
This enables the following tests which rely on instruction vperm which
is available since z13 with the initial vector support.
testsuite/gcc.dg/vect/vect-bswap16.c
42:/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
{ vect_bswap || sse4_runtime } } } } */
In certain cases a constant may not fit into the mode used to perform a
comparison. This may be the case for sign-extended constants which are
used during an unsigned comparison as e.g. in
(set (reg:CC 100 cc)
(compare:CC (mem:SI (reg/v/f:SI 115 [ a ]) [1 *a_4(D)+0 S4 A64])
On Tue, Aug 01, 2023 at 01:52:16PM +0530, Prathamesh Kulkarni wrote:
> On Tue, 1 Aug 2023 at 05:20, Jeff Law wrote:
> >
> >
> >
> > On 7/31/23 15:43, Prathamesh Kulkarni via Gcc-patches wrote:
> > > On Mon, 19 Jun 2023 at 19:59, Stefan Schulze Friel
ping
On Mon, Jun 19, 2023 at 04:23:57PM +0200, Stefan Schulze Frielinghaus 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
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 <= 0x3fff
results in the constant being spilled to
On Mon, Jun 12, 2023 at 03:29:00PM -0600, Jeff Law wrote:
>
>
> On 6/12/23 01:57, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > Comparisons between memory and constants might be done in a smaller mode
> > resulting in smaller constants which might finally
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 <= 0x3fff
results in the constant being spilled to
So far atomic objects are aligned according to their default alignment.
For 128 bit scalar types like int128 or long double this results in an
8 byte alignment which is wrong and must be 16 byte.
libstdc++ already computes a correct alignment, though, still adding a
test case in order to make
Vectorize memset with a constant length of less than or equal to 64
bytes.
Do not perform a libc function call into memset in case the size is not
a compile-time constant but bounded and the upper bound is less than or
equal to 256 bytes.
gcc/ChangeLog:
* config/s390/s390-protos.h
Do not perform a libc function call into memcpy in case the size is not
a compile-time constant but bounded and the upper bound is less than or
equal to 256 bytes.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_cpymem): Change
function signature.
*
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_movmem): New.
* config/s390/s390.cc (s390_expand_movmem): New.
* config/s390/s390.md (movmem): New.
(*mvcrl): New.
(mvcrl): New.
---
gcc/config/s390/s390-protos.h | 1 +
gcc/config/s390/s390.cc
Bootstrapped and regtested. Ok for mainline?
Stefan Schulze Frielinghaus (3):
s390: Refactor block operation cpymem
s390: Add block operation movmem
s390: Refactor block operation setmem
gcc/config/s390/s390-protos.h| 5 +-
gcc/config/s390/s390.cc | 301
This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
introducing a runtime check for alignment for 16 byte atomic
compare-exchange, load, and store.
Bootstrapped and regtested on s390.
Ok for mainline and gcc-{12,11,10}?
libatomic/ChangeLog:
* config/s390/cas_n.c: New
Use constrain_operands in order to check whether there exists a valid
alternative instead of extract_constrain_insn which ICEs in case no
alternative is found.
Bootstrapped and regtested on IBM zSystems. Ok for mainline?
gcc/ChangeLog:
* config/s390/predicates.md (execute_operation):
So far we propagate scheduler state across basic blocks within EBBs and
reset the state otherwise. In certain circumstances the entry block of
an EBB might be empty, i.e., no_real_insns_p is true. In those cases
scheduler state is not reset and subsequently wrong state is propagated
to following
In the context of D the interpretation of S390, S390X, and SystemZ is a
bit fuzzy. The wording S390X was wrongly deprecated in favour of
SystemZ by commit
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for
On Mon, Jan 23, 2023 at 02:21:46PM +0100, Iain Buclaw wrote:
> Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar
> 13, 2023 6:54 pm:
> > In the context of D the interpretation of S390, S390X, and SystemZ is a
> > bit fuzzy. The wording S390X was
In the context of D the interpretation of S390, S390X, and SystemZ is a
bit fuzzy. The wording S390X was wrongly deprecated in favour of
SystemZ by commit
https://github.com/dlang/dlang.org/commit/3b50a4c3faf01c32234d0ef8be5f82915a61c23f
Thus, SystemZ is used for 64-bit targets, now, and S390 for
On Thu, Nov 24, 2022 at 05:53:53PM +0100, Richard Biener wrote:
>
>
> > Am 24.11.2022 um 17:28 schrieb Stefan Schulze Frielinghaus via Gcc
> > :
> >
> > Hi everyone,
> >
> > Currently I'm looking into a wrong-code bug and would like to understand
Hi everyone,
Currently I'm looking into a wrong-code bug and would like to understand
a certain optimization done by combine during local transformation.
Without LTO I would simply debug cc1 and step through combine. However,
with LTO enabled AFAIK I have to debug lto1 instead. In order to get
On Wed, Oct 05, 2022 at 08:48:13PM -0600, Jeff Law via Gcc-patches wrote:
>
> On 10/4/22 05:28, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > For BImode get_narrowest_mode evaluates to QImode but BImode < QImode.
> > Thus FOR_EACH_MODE_UNTIL never reaches BImode and
For BImode get_narrowest_mode evaluates to QImode but BImode < QImode.
Thus FOR_EACH_MODE_UNTIL never reaches BImode and iterates until OImode
for which no wider mode exists so we end up with VOIDmode and fail.
Fixed by adding a size guard so we effectively skip BImode.
Bootstrap and regtest are
Ping.
On Wed, Sep 07, 2022 at 04:20:26PM +0200, Stefan Schulze Frielinghaus wrote:
> For parameter of type integer which do not consume a whole register
> (modulo sign/zero extension) this patch adds entry values up to maximal
> register mode.
>
> gcc/ChangeLog:
>
> * var-tracking.cc
Ping.
On Wed, Sep 07, 2022 at 04:20:25PM +0200, Stefan Schulze Frielinghaus wrote:
> Whenever a new cselib value is created check whether a smaller value
> exists which is contained in the bigger one. If so add a subreg
> relation to locs of the smaller one.
>
> gcc/ChangeLog:
>
> *
For parameter of type integer which do not consume a whole register
(modulo sign/zero extension) this patch adds entry values up to maximal
register mode.
gcc/ChangeLog:
* var-tracking.cc (vt_add_function_parameter): Add entry values
up to maximal register mode.
---
Whenever a new cselib value is created check whether a smaller value
exists which is contained in the bigger one. If so add a subreg
relation to locs of the smaller one.
gcc/ChangeLog:
* cselib.cc (new_cselib_val): Keep track of further subvalue
relations.
---
gcc/cselib.cc |
For variable tracking there exists cases where a value is moved in a
wider mode than its native mode. For example:
int
foo (int x)
{
bar (x);
return x;
}
compiles on IBM zSystems into
0x010012b0 <+0>: stmg%r12,%r15,96(%r15)
0x010012b6 <+6>: lgr %r12,%r2
On Wed, Aug 17, 2022 at 01:50:45PM +0200, Stefan Schulze Frielinghaus wrote:
> For a parameter with BLKmode we cannot use REG_NREGS in order to
> determine the number of consecutive registers. Streamlined this with
> the implementation of s390_function_arg.
>
> Fix some indentation whitespace,
For my current use case only some FOR_EACH_MODE macros were missing.
Though I thought I will give it a try and grep'ed through the source
code and added further ones. I didn't manually check all of them but so
far it looks good to me.
Ok for mainline?
contrib/ChangeLog:
* clang-format:
For a parameter with BLKmode we cannot use REG_NREGS in order to
determine the number of consecutive registers. Streamlined this with
the implementation of s390_function_arg.
Fix some indentation whitespace, too.
Assuming bootstrap and regtest are ok for mainline and gcc-{10,11,12},
ok to
On Mon, Aug 01, 2022 at 12:25:21PM +0100, Jonathan Wakely wrote:
> On Mon, 1 Aug 2022 at 09:24, Stefan Schulze Frielinghaus wrote:
> > I gave unexpand from GNU coreutils 8.32 a try. Looks like it cannot
> > deal with form feeds or maybe I'm missing something?
> >
> > $ bash -c "printf 'foo\n\f\n
On Thu, Jul 28, 2022 at 08:53:37PM +0100, Jonathan Wakely via Gcc wrote:
> On Thu, 28 Jul 2022 at 20:49, Tim Lange wrote:
> >
> >
> >
> > On Thu, Jul 28 2022 at 02:46:58 PM -0400, David Malcolm via Gcc
> > wrote:
> > > Is there documentation on setting up text editors to work with our
> > >
On Tue, Apr 26, 2022 at 04:40:33PM +0200, Hans-Peter Nilsson wrote:
> > From: Thomas Koenig via Gcc-patches
> > Date: Fri, 22 Apr 2022 15:59:45 +0200
>
> > Hi Mikael,
> >
> > > Ping for the four patches starting at
> > > https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
> > >
For a peephole2 condition variable insn points to the first matched
insn. In order to refer to the second matched insn use
peep2_next_insn(1) instead.
Update: Added a test case
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
gcc/ChangeLog:
*
For a peephole2 condition variable insn points to the first matched
insn. In order to refer to the second matched insn use
peep2_next_insn(1) instead.
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
gcc/ChangeLog:
* config/s390/s390.md (define_peephole2):
On Tue, Nov 02, 2021 at 04:20:01PM +0100, Andreas Schwab wrote:
> On Nov 02 2021, Stefan Schulze Frielinghaus via Gcc-patches wrote:
>
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > b/gcc/testsuite/gcc.dg/tree-ssa/ldist-rawmemchr-1.c
> > index
Bootstrapped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* config/s390/s390.c (s390_loop_unroll_adjust): In case of early
exit free bbs.
---
gcc/config/s390/s390.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c
The tests require vector extensions which are only available for z13 and
later while using the z/Architecture.
Bootstrapped and regtested on IBM Z. Ok for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ldist-rawmemchr-1.c: For IBM Z set arch to z13
and use z/Architecture
Since a recent enhancement of -Waddress a couple of warnings are emitted
and turned into errors during bootstrap:
gcc/config/s390/s390.md:12087:25: error: the address of 'operands' will never
be NULL [-Werror=address]
12087 | "TARGET_HTM && operands != NULL
build/gencondmd.c:59:12: note:
ping
On Mon, Oct 11, 2021 at 02:14:53PM +0200, Stefan Schulze Frielinghaus wrote:
> On Mon, Oct 11, 2021 at 09:38:36AM +0200, Richard Biener wrote:
> > On Fri, Oct 8, 2021 at 1:31 PM Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> >
While determining the precission of reduction_var an SSA_NAME instead of
its TREE_TYPE is used. Streamlined with other TREE_TYPE (reduction_var)
uses.
Bootstrapped and regtested on x86 and IBM Z. Committed as per PR102752.
gcc/ChangeLog:
* tree-loop-distribution.c
On Fri, Sep 17, 2021 at 10:08:27AM +0200, Richard Biener wrote:
> On Mon, Sep 13, 2021 at 4:53 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> > > On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
> > > wrote:
> > > >
>
On Mon, Oct 11, 2021 at 09:38:36AM +0200, Richard Biener wrote:
> On Fri, Oct 8, 2021 at 1:31 PM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > gcc/ChangeLog:
> >
> > * regcprop.c (maybe_mode_change): Determine offset relative to
> >
On Thu, Oct 07, 2021 at 11:16:24AM +0200, Andreas Krebbel wrote:
> On 9/20/21 11:24, Stefan Schulze Frielinghaus wrote:
> > This patch implements the rawmemchr expander as introduced in
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579649.html
> >
> > Bootstrapped and regtested in
gcc/ChangeLog:
* regcprop.c (maybe_mode_change): Determine offset relative to
high or low part depending on endianness.
Bootstrapped and regtested on IBM Z. Ok for mainline and gcc-{11,10,9}?
---
gcc/regcprop.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
This patch implements the rawmemchr expander as introduced in
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579649.html
Bootstrapped and regtested in conjunction with the patch from above on
IBM Z. Ok for mainline?
>From 551362cda54048dc1a51588112f11c070ed52020 Mon Sep 17 00:00:00
On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
> > [...]
> > > > >
> > > > > + /* Handle strlen like loops. */
> > > > > + if
On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
[...]
> > >
> > > + /* Handle strlen like loops. */
> > > + if (store_dr == NULL
> > > + && integer_zerop (pattern)
> > > + && TREE_CODE (reduction_iv.base) == INTEGER_CST
> > > + && TREE_CODE (reduction_iv.step) ==
ping
On Fri, Jun 25, 2021 at 12:23:32PM +0200, Stefan Schulze Frielinghaus wrote:
> On Wed, Jun 16, 2021 at 04:22:35PM +0200, Richard Biener wrote:
> > On Mon, Jun 14, 2021 at 7:26 PM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze
On Wed, Jun 16, 2021 at 04:22:35PM +0200, Richard Biener wrote:
> On Mon, Jun 14, 2021 at 7:26 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze Frielinghaus wrote:
> > [...]
> > > > but we won't ever arrive here because of the niters
On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze Frielinghaus wrote:
[...]
> > but we won't ever arrive here because of the niters condition. But
> > yes, doing the pattern matching in the innermost loop processing code
> > looks good to me - for the specific case it would be
> >
> >
On Thu, May 20, 2021 at 11:24:57AM +0200, Richard Biener wrote:
> On Fri, May 7, 2021 at 2:32 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Wed, May 05, 2021 at 11:36:41AM +0200, Richard Biener wrote:
> > > On Tue, Mar 16, 2021 at 6:13 PM Stefan Schulze Frielinghaus
> > > wrote:
> > > >
> >
The type of the output operands *p and *q of the extended asm statement
of function foo is unsigned long whereas the type of the corresponding
input operands is int. This results, e.g. on IBM Z, in the case that
the immediates 2 and 3 are written into registers in SI mode and read in
DI mode
On Wed, May 05, 2021 at 11:36:41AM +0200, Richard Biener wrote:
> On Tue, Mar 16, 2021 at 6:13 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > [snip]
> >
> > Please find attached a new version of the patch. A major change compared to
> > the previous patch is that I created a separate pass which
For move2add_valid_value_p we also have to ask the target whether a
register can be accessed in a different mode than it was set before.
gcc/ChangeLog:
PR rtl-optimization/100263
* postreload.c (move2add_valid_value_p): Ensure register can
change mode.
Bootstrapped and
ping
On Thu, Apr 08, 2021 at 10:23:31AM +0200, Stefan Schulze Frielinghaus wrote:
> ping
>
> On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> > [snip]
> >
> > Please find attached a new version of the patch. A major change compared to
> > the previous patch is
The test fails for targets with V4QImode support which is the case for
IBM Z.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr71264.c: Xfail on IBM Z due to V4QImode support.
Ok for mainline?
---
gcc/testsuite/gcc.dg/vect/pr71264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On IBM Z the aliasing stores are realized through one element vector
instructions, if no cost model for vectorization is used which is the
default according to vect.exp. Fixed by changing the number of times
the pattern must be found in the dump.
gcc/testsuite/ChangeLog:
*
Depending on whether GCC is configured using --with-mode=zarch or not,
for the 31bit target instructions are generated either for ESA or
z/Architecture. For the sake of simplicity and robustness test only for
the latter by adding manually option -mzarch.
gcc/testsuite/ChangeLog:
*
For z10 and newer inner loops are completely unrolled which means store
motion is not applied. Reverting max-completely-peeled-insns to the
default value fixes these testcases.
Ok for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr83403-1.c: Revert
On s390* the only missing part for the mentioned testcases was a load of
a double floating-point zero via a move (in particular for quite old
machines) which was added in commit 46c47420a5fefd4d9d02b0db347235dd74e20fb2.
Common code implementation is sufficient in order to clear volatile
GPRs,
For z10 and newer inner loops are completely unrolled which leaves no
inner loops to jam which renders this testcase to fail. Reverting
max-completely-peel-times to the default value fixes this testcase.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-and-jam.c: Revert
Regarding test gcc.dg/pr93210.c, on different targets GIMPLE code may
slightly differ which is why the scan-tree-dump-times directive may
fail. For example, for a RETURN_EXPR on x86_64 we have
return 0x11100f0e0d0c0a090807060504030201;
whereas on IBM Z the first operand is a RESULT_DECL like
Bootstraped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
alternative in order to load a DFP zero.
---
gcc/config/s390/s390.md | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
ping
On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> [snip]
>
> Please find attached a new version of the patch. A major change compared to
> the previous patch is that I created a separate pass which hopefully makes
> reviewing also easier since it is almost
[snip]
Please find attached a new version of the patch. A major change compared to
the previous patch is that I created a separate pass which hopefully makes
reviewing also easier since it is almost self-contained. After realizing that
detecting loops which mimic the behavior of
In addition to the existing check also ask the target whether a
replacement register may be accessed in a different mode than it was set
before.
Bootstrapped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* regcprop.c (find_oldest_value_reg): Ask target whether
On Tue, Mar 02, 2021 at 01:29:59PM +0100, Richard Biener wrote:
> On Sun, Feb 14, 2021 at 11:27 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> > > On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielin
On Tue, Mar 02, 2021 at 08:08:14AM +0100, Andreas Krebbel wrote:
> On 3/1/21 5:00 PM, Stefan Schulze Frielinghaus wrote:
> > As of commit 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 expressions
> > x CMP y ? -1 : 0 are fold into x CMP y. Due to this we do not see
> > shifts anymore after expand in
As of commit 3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1 expressions
x CMP y ? -1 : 0 are fold into x CMP y. Due to this we do not see
shifts anymore after expand in our testcases but comparisons. Thus
replace instructions vesraX by corresponding vchX. Keep testcases
vchX_{lt,gt} where only a
1 - 100 of 157 matches
Mail list logo
