On 2/11/23 17:10, Stefan Schulze Frielinghaus wrote:
> 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/Chan
On 2/11/23 16:59, Stefan Schulze Frielinghaus wrote:
> 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 r
On 2/27/23 11:13, Robin Dapp wrote:
>> Do you really need a copy of the address register? Couldn't you just do a
>> src = adjust_address (operands[1], BLKmode, 0);
>> You create a paradoxical subreg of the QImode input but vll actually
>> uses the whole 32 bit value. Couldn't we end up with uniniti
On 3/2/23 19:17, Robin Dapp wrote:
> Hi,
>
> When compiling on a system where binutils do not yet support the 'z16'
> name assembling fails with -march=native which we currently interpret
> as -march=z16 (on a z16 machine). This patch uses -march=arch14
> instead.
>
> Is it OK?
Ok. Thanks!
And
On 3/2/23 16:24, Stefan Schulze Frielinghaus wrote:
> 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,
On 3/2/23 19:13, Robin Dapp wrote:
> Hi,
>
> we seem to flip flop between the "high" and "not low" variants of load on
> condition. Accept both in the affected test cases.
>
> Going to commit this as obvious.
>
> Regards
> Robin
>
> --
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s39
On 5/15/23 09:17, Stefan Schulze Frielinghaus wrote:
> 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
On 5/16/23 08:43, Stefan Schulze Frielinghaus wrote:
> 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 al
On 3/20/23 07:33, Kewen.Lin wrote:
> Hi,
>
> One of my workmates found there is a warning like:
>
> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
> incorrect section type for .init_array.0
>
> when compiling libgcc/config/rs6000/morestack.S.
>
> Since commit r13-6545 touched
On 1/18/21 10:54 PM, Ilya Leoshkevich wrote:
...
> +static rtx_insn *
> +s390_md_asm_adjust (vec &outputs, vec &inputs,
> + vec &input_modes,
> + vec &constraints, vec & /*clobbers*/,
> + HARD_REG_SET & /*clobbered_regs*/)
> +{
> + if (!TARGET_VXE)
On 2/18/21 1:57 PM, Ilya Leoshkevich wrote:
> This series fixes PR99134. Patch 1 is factored out from the pending
> [1], patch 2 is the actual fix. Bootstrapped and regtested on
> s390x-redhat-linux. Ok for master?
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
>
>
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 our testcases but comparisons. Thus
> replace instructions vesraX by corre
gcc/testsuite/ChangeLog:
* gcc.target/s390/mul-signed-overflow-1.c: Run only on z14.
* gcc.target/s390/mul-signed-overflow-2.c: Run only on z14.
---
gcc/testsuite/gcc.target/s390/mul-signed-overflow-1.c | 2 +-
gcc/testsuite/gcc.target/s390/mul-signed-overflow-2.c | 2 +-
2 files
Prepare GCC for a future architecture extension.
gcc/ChangeLog:
* common/config/s390/s390-common.c (processor_flags_table): New entry.
* config.gcc: Enable arch14 for --with-arch and --with-tune.
* config/s390/driver-native.c (s390_host_detect_local_cpu): Pick
arch
This adds support for 5 new builtins.
gcc/ChangeLog:
* config/s390/s390-builtin-types.def (BT_FN_V4SF_V8HI_UINT): New
builtin signature.
(BT_FN_V8HI_V8HI_UINT): Likewise.
(BT_FN_V8HI_V4SF_V4SF_UINT): Likewise.
* config/s390/s390-builtins.def (B_NNPA): New m
On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
> mul-signed-overflow-*.c execution tests fail on z13, because they
> contain z14-specific instructions. Fix by requiring s390_z14_hw
> target.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/mul-signed-overflow-1.c: Run only on z14+.
>
On 3/3/21 11:50 AM, Ilya Leoshkevich wrote:
> On Wed, 2021-03-03 at 07:50 +0100, Andreas Krebbel wrote:
>> On 3/2/21 11:59 PM, Ilya Leoshkevich wrote:
>>> mul-signed-overflow-*.c execution tests fail on z13, because they
>>> contain z14-specific instructions. F
On 3/4/21 3:08 PM, Ilya Leoshkevich wrote:
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563799.html
> v1 -> v2:
> - Handle constraint modifiers, use AR constraint instead of R, add
> testcases for & and %.
>
> v2: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564380.html
Due to a common code change the comparison in the testcase is emitted
via vec_cmp instead of vcond. The testcase checks for an optimization
currently only available via vcond.
Fixed by implementing the same optimization also in
s390_expand_vec_compare.
Bootstrapped and regression tested on s390x
On 03.09.20 08:39, Ilya Leoshkevich wrote:
> Bootstrapped (with BOOT_CFLAGS='-g -O2 -Wno-error=maybe-uninitialized')
> and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Certain alternatives of *vec_tf_to_v1tf use "v" constraint for its
> TFmode source operand. Therefore it is assigned
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 floating-point register of interest into a single load
> and test instruction.
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 is due to the aggressive inlining settings here.
> Some of these warnings
On 01.10.20 11:13, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes
> -FAIL: gcc.dg/pr94780.c (internal compiler error)
> -FAIL: gcc.dg/pr94780.c (test for excess errors)
> -FAIL: gcc.dg/pr94842.c (internal compiler error)
> -FAIL: gcc.dg/pr94842.c (test for excess errors)
> on s390x-linux
gcc/ChangeLog:
* doc/invoke.texi: Add z15/arch13 to the list of documented
-march/-mtune options.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index f623467b763..7c81d7f41bd 100644
--- a/gcc/d
On 08.10.20 11:38, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. OK for master?
>
> The vector copysign pattern incorrectly assumes that vector
> if_then_else operates on bits, not on elements. This can theoretically
> mislead the optimizers. Fix by changing it to
On 09.10.20 17:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. OK for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555782.html
> v1 -> v2: Use related_int_vector_mode.
>
>
>
> The vector copysign pattern incorrectly assumes that vector
On 3/5/22 09:33, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for index registers is used instead for M3 what
>
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in an FPR only if it has
exactly one member. On the other hand it says that structs of 1,2,4,8
bytes are passed in a GPR. So this struct is expected to be passed i
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
> s390 the test's while loop is converted into a rawmemchr builtin making
> it impossible to determine that the pointers *p and *q are related.
>
> Therefore, disable the tree loop di
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> we have been emitting the "higher" variantes instead of the "not less or
> equal" ones for a while. Change the test expectations accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/ifcvt-two-
On 4/4/22 13:52, Robin Dapp wrote:
> Hi,
>
> some tests expect a convert instruction but nowadays the conversion is
> already done at compile time. This results in a literal-pool load.
> Change the tests accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
>
On 4/6/22 17:32, Segher Boessenkool wrote:
> This test fails with error "AltiVec argument passed to unprototyped
> function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
> from 2005) actually tests for any vector type argument. It also does
> not fail on Darwin, not reflected here t
v2:
- Remove redundant num_zero_width_bf_seen and num_fields_seen
tracking. (Thanks Stefan Schulze-Frielinghaus)
Re-tested with testsuite and ABI tests.
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc (s390_host_de
On 4/14/22 05:10, Kewen.Lin wrote:
> Hi,
>
> The test case pr105250.c is like its related pr105140.c, which
> suffers the error with message like "{AltiVec,vector} argument
> passed to unprototyped" on powerpc and s390. So like commits
> r12-8025 and r12-8039, this fix is to add the dg-skip-if fo
On 4/13/22 09:35, Robin Dapp wrote:
> Hi,
>
> this test case checks that we do not ICE but FAILs because of
> -Wint-to-pointer-cast. Silence this warning.
>
> Is it OK?
Ok. Thanks!
Andreas
On 4/13/22 12:23, Robin Dapp wrote:
> Hi,
>
> this patch adds the scheduler description for z16. Bootstrapped and
> regtested with --with-arch=z16.
>
> Is it OK?
>
> Regards
> Robin
>
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_get_sched_attrmask): Add z16.
> (s390_get_un
On 4/13/22 09:30, Richard Biener via Gcc wrote:
>
> Status
> ==
>
> The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> candidate and the GCC 11.3 release next week. All changes now require
> release manager approval.
Hi,
I would like to push:
https://gcc.gnu.org/piper
On 1/20/22 23:52, Richard Sandiford wrote:
> cc:ing the x86 and s390 maintainers
>
> soeren--- via Gcc-patches writes:
>> From: Sören Tempel
>>
>> The -fsplit-stack option requires the pthread_t TCB definition in the
>> libc to provide certain struct fields at specific hardcoded offsets. As
>> f
On 1/20/22 17:13, Robin Dapp wrote:
> Hi,
>
> this patch splits the CCSmode into an integer and a floating point
> variant. This allows ifcvt to consider floating point compares which
> would be rejected before because they could not be reversed.
>
> Bootstrapped and regtested on s390x.
>
> Is
On 1/20/22 11:10, Robin Dapp wrote:
> Hi,
>
> this patch is a follow-up patch to the recent ifcvt changes. It
> increased costs for a load on condition to 6. This ensures that we
> if-convert sequences of three regular instructions (of cost 4) e.g. a
> compare and two SETs into two loads on condi
When propagating a multi-word register into an access with a smaller
mode the can_change_mode backend hook is already consulted for the
original register. This however is also required for the intermediate
copy in copy_regno which might use a different register class.
Bootstrapped on x86_64 and s
On 2/1/22 21:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section (current_function_se
On 2/2/22 12:57, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for
> releases/gcc-11?
>
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section (curre
MASK_MVCLE is set for -Os but not for other optimization levels. In
general it should not make much sense to inline across calls where the
flag is different but we have to allow it for always_inline.
The patch also rearranges the hook implementation a bit based on the
recommendations from Jakub un
On 2/7/22 09:11, Jakub Jelinek wrote:
...
> 1) formatting, = should be at the start of next line rather than end of the
>line
> 2) all_masks, always_inline_safe_masks and caller_required_masks aren't
>ever modified, perhaps make them const?
> 3) I wonder if there is any advantage to have al
On 2/25/22 12:38, Robin Dapp wrote:
> Hi,
>
> the IF_THEN_ELSE detection currently prevents us from properly costing
> register-register moves which causes the lower-subreg pass to assume
> that a VR-VR move is as expensive as two GPR-GPR moves.
>
> This patch adds handling for SETs containing RE
On 11/19/21 10:45, Stefan Schulze Frielinghaus wrote:
...
> diff --git a/gcc/testsuite/gcc.target/s390/2029.c
> b/gcc/testsuite/gcc.target/s390/2029.c
> new file mode 100644
> index 000..1a6df4f4b89
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/2029.c
> @@ -0,0 +1,12 @@
On 10/19/22 08:22, Robin Dapp wrote:
> Hi,
>
> since r13-2746 we hit an ICE when bootstrapping with -m31 and
> --enable-checking=all.
>
> ../../../../libgfortran/ieee/ieee_helper.c: In function
> 'ieee_class_helper_16':
> ../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler
> error:
On 8/17/22 13:50, 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, too.
>
> Assuming bootstr
On 8/12/22 12:00, Robin Dapp wrote:
> Hi,
>
> inspired by Power we also introduce -munroll-only-small-loops. This
> implies activating -funroll-loops and -munroll-only-small-loops at -O2
> and above.
>
> Bootstrapped and regtested.
>
> This introduces one regression in gcc.dg/sms-compare-debug-
On 8/12/22 12:02, Robin Dapp wrote:
> Hi,
>
> this patch tries to be more explicit by mentioning z15 in s390_issue_rate.
>
> No changes in testsuite, bootstrap or SPEC obviously.
>
> Is it OK?
>
> Regards
> Robin
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_issue_rate): Add z15.
On 8/12/22 12:13, Robin Dapp wrote:
> Hi,
>
> swapping the two elements of a V2DImode or V2DFmode vector can be done
> with vpdi instead of using the generic way of loading a permutation mask
> from the literal pool and vperm.
>
> Analogous to the V2DI/V2DF case reversing the elements of a four-e
On 8/12/22 16:19, Robin Dapp wrote:
> Hi,
>
> vec_select can handle dynamic/runtime masks nowadays. Therefore we can
> get rid of the UNSPEC_VEC_EXTRACT that was preventing further
> optimizations like combining instructions with vec_extract patterns.
>
> Bootstrapped and regtested. No regressio
On 8/12/22 16:48, Robin Dapp wrote:
> Hi,
>
> similar to other backends this patch implements vec_set via
> vec_merge and vec_duplicate instead of an unspec. This opens up
> more possibilites to combine instructions.
>
> Bootstrapped and regtested. No regressions.
>
> Is it OK?
>
> Regards
>
On 8/22/22 17:10, Robin Dapp wrote:
> Hi,
>
> after discussing off-list, here is v2 of the patch. We now recognize if
> the permutation mask only refers to the first or the second operand and
> use this later when emitting vpdi.
>
> Regtested and bootstrapped, no regressions.
>
> Is it OK?
>
>
On 03.11.20 22:36, Ilya Leoshkevich wrote:
> gcc/ChangeLog:
>
> 2020-11-03 Ilya Leoshkevich
>
> * config/s390/s390.md (RRe): Remove.
> (RXe): Remove.
Ok. Thanks!
Andreas
On 03.11.20 22:45, Ilya Leoshkevich wrote:
> gcc/ChangeLog:
>
> 2020-11-03 Ilya Leoshkevich
>
> * config/s390/s390.c (NR_C_MODES): Unhardcode.
> (s390_alloc_pool): Use size_t for iterating from 0 to
> NR_C_MODES.
> (s390_add_constant): Likewise.
> (s390_find_const
On 03.11.20 22:45, Ilya Leoshkevich wrote:
> On z14+, there are instructions for working with 128-bit floats (long
> doubles) in vector registers. It's beneficial to use them instead of
> instructions that operate on floating point register pairs, because it
> allows to store 4 times more data in
These tests all use the -mzvector option but do not appear to make use of the z
vector languages
extensions. I think that option could be removed. Then these tests should be
moved to the vector subdir.
You could do the asm scanning also in dg-do run tests.
Andreas
On 03.11.20 22:46, Ilya Leos
On 04.11.20 23:12, Ilya Leoshkevich wrote:
> On Wed, 2020-11-04 at 18:16 +0100, Andreas Krebbel wrote:
>> On 03.11.20 22:45, Ilya Leoshkevich wrote:
>>> On z14+, there are instructions for working with 128-bit floats
>>> (long
>>> doubles) in vector registers.
On 04.11.20 23:19, Ilya Leoshkevich wrote:
> On Wed, 2020-11-04 at 18:28 +0100, Andreas Krebbel wrote:
>> These tests all use the -mzvector option but do not appear to make
>> use of the z vector languages
>> extensions. I think that option could be removed. Then these tests
On 06.11.20 04:52, Jeff Law via Gcc-patches wrote:
>
> On 10/30/20 7:01 AM, Richard Biener wrote:
>>
>> It's not that more / different inlining inherently exposes _more_
>> false positives in the middle-end warnings. They simply expose
>> others and the GCC codebase is cleansed (by those who chan
On 09.11.20 20:54, Ilya Leoshkevich wrote:
> On z14+, there are instructions for working with 128-bit floats (long
> doubles) in vector registers. It's beneficial to use them instead of
> instructions that operate on floating point register pairs, because it
> allows to store 4 times more data in
On 09.11.20 20:54, Ilya Leoshkevich wrote:
> gcc/testsuite/ChangeLog:
>
> 2020-11-05 Ilya Leoshkevich
>
> * gcc.target/s390/vector/long-double-callee-abi-scan.c: New test.
> * gcc.target/s390/vector/long-double-caller-abi-run.c: New test.
> * gcc.target/s390/vector/long-doubl
On 10.11.20 18:43, Ilya Leoshkevich wrote:
> Bootstrap and regtest running on s390x-redhat-linux with --enable-shared
> --with-system-zlib --enable-threads=posix --enable-__cxa_atexit
> --enable-checking=yes,rtl --enable-gnu-indirect-function
> --disable-werror --enable-languages=c,c++,fortran,objc
Just a preparation to add a lower-case tointvec.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
* config/s390/vector.md: Rename tointvec to TOINTVEC.
* config/s390/vx-builtins.md: Likewise.
---
gcc/config/s390/vector.md | 142 -
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
PR target/97326
* config/s390/vector.md: Support vector floating point modes in
vec_cmp.
---
gcc/config/s390/vector.md | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/g
On 12.11.20 13:25, Stefan Schulze Frielinghaus wrote:
> 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 del
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/s390/vector.md | 26 ++
> 1 file changed, 26 insertions(+)
On 13.11.20 23:23, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on z13 s390x-redhat-linux. Ok for master?
>
> gcc/testsuite/ChangeLog:
>
> 2020-11-12 Ilya Leoshkevich
>
> * gcc.target/s390/s390.exp (check_effective_target_s390_z14_hw):
> New predicate.
> * gcc.targe
Avoid emitting a strict low part move if the insv target actually
affects the whole target reg.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
PR target/10
* config/s390/s390.c (s390_expand_insv): Emit a normal move if it
is actually a full copy of the so
The code sequence emitted uses CC internally.
gcc/ChangeLog:
* config/s390/tpf.md (prologue_tpf, epilogue_tpf): Add cc clobber.
---
gcc/config/s390/tpf.md | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/tpf.md b/gcc/config/s390/tpf.md
index 297e9
On 9/30/21 10:50, Ilya Leoshkevich wrote:
> Hi,
>
> This series contains a backport of kpatch changes needed to support
> https://github.com/dynup/kpatch/pull/1203 so that it could be used in
> RHEL 9. The patches have been in master for 4 months now without
> issues.
>
> Bootstrapped and regtes
On 10/30/21 12:43, Stefan Schulze Frielinghaus wrote:
> 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 | "TA
On 11/2/21 15:54, Stefan Schulze Frielinghaus wrote:
> 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-rawmem
On 11/2/21 18:31, Stefan Schulze Frielinghaus wrote:
> 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.
Ok. Thanks!
Andreas
With -fstack-check the stack probes emitted access memory below the
stack pointer.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
* config/s390/s390.h (STACK_CHECK_MOVING_SP): New macro
definition.
---
gcc/config/s390/s390.h | 5 +
1 file
This prevents find_cond_trap from being invoked after reload. It may
generate compares which would require reloading.
Bootstrapped and regression tested on s390x.
Ok for mainline?
gcc/ChangeLog:
PR rtl-optimization/103028
* ifcvt.c (find_if_header): Invoke find_cond_trap only b
On 11/5/21 20:34, Jeff Law wrote:
>
>
> On 11/5/2021 4:19 AM, Andreas Krebbel via Gcc-patches wrote:
>> This prevents find_cond_trap from being invoked after reload. It may
>> generate compares which would require reloading.
>>
>> Bootstrapped and regress
On 6/2/21 4:21 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Since commit dd1ef00c45ba ("Fix bug in the define_subst handling that
> made match_scratch unusable for multi-alternative patterns.") the
> workaround for that bug in *ashrdi3_3
On 6/9/21 2:47 PM, Robin Dapp wrote:
>> I think the real problem is the expander name. That's why it could not be
>> found by optab. The second
>> mode needs to be the int vector mode of op3. With that change the testcases
>> work as expected:
>>
>> diff --git a/gcc/config/s390/vector.md b/gcc/co
[2]) == &q[19])); \
> + q[19] = (T) 0xaaaa; \
> + /* unaligned + 4th load */ \
> + q[25] = pattern; \
> + assert ((rawmemchr_##T (&q[2]) == &q[25])); \
> + q[25] = (T) 0x;
On 10/8/21 16:23, Stefan Schulze Frielinghaus wrote:
> 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
On 7/12/21 9:23 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573614.html
> v1 -> v2: Do not use UNSPEC_PLT in 64-bit code and rename it to
> UNSPEC_PLT31 (Ulrich, Andreas). Do
There are also memory operands passed for in0 and in1.
Ok for mainline?
gcc/ChangeLog:
* target.def: Describe in0 and in1 as being either register or
memory operands.
* doc/tm.texi: Regenerate.
---
gcc/doc/tm.texi | 7 ---
gcc/target.def | 7 ---
2 files changed
On 7/27/21 10:04 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> libsanitizer/ChangeLog:
>
> * configure.tgt (s390*-*-linux*): Enable LSan and TSan for
> s390x.
Ok. Thanks!
Andreas
On 7/28/21 9:43 AM, Richard Biener wrote:
> On Wed, Jul 28, 2021 at 8:44 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> There are also memory operands passed for in0 and in1.
>>
>> Ok for mainline?
>
> They can also be constant vectors, I'd just
On 7/23/21 2:47 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/global-array-element-pic2.c: Add -mzarch, add
> an expectation for 31-bit mode.
> * gcc.target/s390/load-imm64
This patch implements the TARGET_VECTORIZE_VEC_PERM_CONST in the IBM Z
backend. The initial implementation only exploits the vector merge
instruction but there is more to come.
gcc/ChangeLog:
* config/s390/s390.c (MAX_VECT_LEN): Define macro.
(struct expand_vec_perm_d): Define str
This patch makes use of the vector permute double immediate
instruction for constant permute vectors.
gcc/ChangeLog:
* config/s390/s390.c (expand_perm_with_vpdi): New function.
(vectorize_vec_perm_const_1): Call expand_perm_with_vpdi.
* config/s390/vector.md (*vpdi1, @vpdi
expected various occurrences of the vperm instruction get replaced
with vmr* and vpdi.
I'll commit the patches after giving it a few days for comments.
Andreas Krebbel (5):
IBM Z: Get rid of vec merge unspec
IBM Z: Get rid of vpdi unspec
IBM Z: Remove redundant V_HW_64 mode iterator.
The patch gets rid of the unspec used for the vector permute double
immediate instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390.md (UNSPEC_VEC_PERMI): Remove constant
definition.
* config/s390/vector.md (*vpdi1, *vpdi4): New pattern
de
gcc/ChangeLog:
* config/s390/vector.md (V_HW_64): Remove mode iterator.
(*vec_load_pair): Use V_HW_2 instead of V_HW_64.
* config/s390/vx-builtins.md
(vec_scatter_element_SI): Use V_HW_2 instead of
V_HW_64.
---
gcc/config/s390/vector.md | 7 +++
g
This patch gets rid of the unspecs we were using for the vector merge
instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390-modes.def: Add more vector modes to support
concatenation of two vectors.
* config/s390/s390-protos.h (s390_expand_merge_pe
The problem appears to be triggered by two locations in the front-end
where non-POINTER_SIZE pointers aren't handled right now.
1. An assertion in strip_typedefs is triggered because the alignment
of the types don't match. This in turn is caused by creating the new
type with build_pointer_type ins
On 4/28/21 10:12 AM, Richard Biener wrote:
> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> The problem appears to be triggered by two locations in the front-end
>> where non-POINTER_SIZE pointers aren't handled right now.
>>
>
On 4/28/21 10:22 AM, Andreas Krebbel via Gcc-patches wrote:
> On 4/28/21 10:12 AM, Richard Biener wrote:
>> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
>> wrote:
>>>
>>> The problem appears to be triggered by two locations in the front-end
&g
On 4/28/21 10:12 AM, Richard Biener wrote:
> On Wed, Apr 28, 2021 at 8:54 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> The problem appears to be triggered by two locations in the front-end
>> where non-POINTER_SIZE pointers aren't handled right now.
>>
>
The problem appears to be triggered by two locations in the front-end
where non-POINTER_SIZE pointers aren't handled right now.
1. An assertion in strip_typedefs is triggered because the alignment
of the types don't match. This in turn is caused by creating the new
type with build_pointer_type ins
901 - 1000 of 1086 matches
Mail list logo
