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:
tree_to_
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
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.
Boot
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): Fix
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 a
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)
F
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 th
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.
* config/s390/vector.
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 } } } } */
testsuite/gcc
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])
(const_int
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 non-
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 sure
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 (s390_
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.
* config/s390/s39
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 f
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): Us
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 wrongly deprecated in f
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 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 c
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 (vt_a
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:
>
> * cseli
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.
---
gcc/var-track
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 | 20
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
0x000
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, to
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 instal
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 :
> > > https
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:
* config/s390/s390.md
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): Variab
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 b/gcc/co
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 s
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: 'opera
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 (reduction_var_overfl
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 c
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(-)
d
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 2001
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 (store_dr
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) == I
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 Friel
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 conditio
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 resul
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 re
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 that
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:
* gcc.dg/vect/bb
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:
* gcc.ta
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
max-completely-peeled-
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, FPRs,
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 max-completely-peel-times
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(-)
dif
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 self-
[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 rawmemchr/strlen
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
differ
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 ou
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 relat
Ping
On Sun, Feb 14, 2021 at 11:27:40AM +0100, 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 Frielinghaus via
> > Gcc-patches wrote:
> > >
> > > This patch a
On Tue, Feb 09, 2021 at 09:57:58AM +0100, Richard Biener wrote:
> On Mon, Feb 8, 2021 at 3:11 PM Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> >
> > This patch adds support for recognizing loops which mimic the behaviour
> > of function rawmemchr, and replace
This patch adds support for recognizing loops which mimic the behaviour
of function rawmemchr, and replaces those with an internal function call
in case a target provides them. In contrast to the original rawmemchr
function, this patch also supports different instances where the memory
pointed to
As pointed out in
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558816.html
this instruction pattern will be removed anyway. Thus we can ignore
this patch.
On Thu, Nov 12, 2020 at 01:25:35PM +0100, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for master?
On Thu, Nov 12, 2020 at 02:18:13PM +0100, Andreas Krebbel wrote:
> On 12.11.20 13:21, Stefan Schulze Frielinghaus wrote:
> > Bootstrapped and regtested on IBM Z. Ok for master?
> >
> > gcc/ChangeLog:
> >
> > * config/s390/vector.md ("vec_vfees"): New insn pattern.
> > ---
> > gcc/config/s39
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/vx-builtins.md ("*vfees"): Fix output
template.
---
gcc/config/s390/vx-builtins.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/vx-builtins.md b/gcc/config/s
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/vector.md ("vec_vfees"): New insn pattern.
---
gcc/config/s390/vector.md | 26 ++
1 file changed, 26 insertions(+)
diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
On Wed, Oct 28, 2020 at 11:34:53AM -0600, Jeff Law wrote:
>
> On 10/28/20 11:29 AM, Stefan Schulze Frielinghaus wrote:
> > On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote:
> >> On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> >>&
On Wed, Oct 28, 2020 at 08:39:41AM -0600, Jeff Law wrote:
>
> On 10/28/20 3:38 AM, Stefan Schulze Frielinghaus via Gcc-patches wrote:
> > On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via
> > Gcc-patches wrote:
> >> On Tue, Sep 22, 2020 a
On Mon, Oct 05, 2020 at 02:02:57PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote:
> > On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote:
> > > Over the last couple of months quite a few warnings a
In case the vectorized version of strlen is used, then each memory
access inside the loop is 16-byte aligned. Thus add this kind of
information so that vector alignment hints can later on be emitted.
Bootstrapped and regtested on IBM Z. Ok for master?
gcc/ChangeLog:
* config/s390/s390.
On Tue, Sep 22, 2020 at 02:59:30PM +0200, Andreas Krebbel wrote:
> On 15.09.20 17:02, Stefan Schulze Frielinghaus wrote:
> > Over the last couple of months quite a few warnings about uninitialized
> > variables were raised while building GCC. A reason why these warnings
> > show up on S/390 only i
On Fri, Oct 02, 2020 at 10:46:33AM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 03:24:08PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> > > On Wed, Sep 30, 2020 at 01:21:44PM
On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> > I think the problem boils down that on S/390 we distinguish between four
> > states of a flag: explicitely set to yes/no and implicitely set to
> > yes/n
On Wed, Sep 30, 2020 at 11:32:55AM +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > This patch breaks quite a view test cases (target-attribute/tattr-*) on
> > IBM Z. Having
On Sun, Sep 13, 2020 at 10:29:22AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Fri, Sep 11, 2020 at 11:29:52AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Fri, Sep 11, 2020 at 09:46:37AM +0200, Christophe Lyon via Gcc-patches
> > wrote:
> > > I'm seeing an ICE with this new test on mos
On Mon, Sep 21, 2020 at 06:51:00PM +0200, Andreas Krebbel wrote:
> On 18.09.20 13:10, Stefan Schulze Frielinghaus wrote:
> > This patch enables a peephole2 optimization which transforms a load of
> > constant zero into a temporary register which is then finally used to
> > compare against a floatin
This patch enables a peephole2 optimization which transforms a load of
constant zero into a temporary register which is then finally used to
compare against a floating-point register of interest into a single load
and test instruction. However, the optimization is only applied if both
registers ar
Over the last couple of months quite a few warnings about uninitialized
variables were raised while building GCC. A reason why these warnings
show up on S/390 only is due to the aggressive inlining settings here.
Some of these warnings (2c832ffedf0, b776bdca932, 2786c0221b6,
1657178f59b) could be
; > > > Richard Biener writes:
> > > > > > > On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford
> > > > > > > wrote:
> > > > > > >>
> > > > > > >> Richard Biener via Gcc-patches writes:
> > > > &g
hard Sandiford
> > > wrote:
> > > >
> > > > Richard Biener writes:
> > > > > On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford
> > > > > wrote:
> > > > >>
> > > > >> Richard Biener via Gcc
>> Richard Biener via Gcc-patches writes:
> > >> > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via
> > >> > Gcc-patches wrote:
> > >> >>
> > >> >> This is a follow up to commit 5c9669a0e6c respectively disc
This is a follow up to commit 5c9669a0e6c respectively discussion
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549132.html
In case that an alignment constraint is less than the size of a
corresponding scalar type, ensure that we advance at least by one
iteration. For example, on s390x we h
gcc/ChangeLog:
* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them. For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS): Define
1 - 100 of 131 matches
Mail list logo
