On 24.11.20 12:55, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Commit 5d9ade39b872 ("IBM Z: Fix PR97326: Enable fp compares in
> vec_cmp") made it possible to create rtxes that describe signaling
> comparisons on z13, which are not
On 23.11.20 22:38, Ilya Leoshkevich wrote:
> Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
> generation: we no longer need "vx x,x,-1", which turned out to be
> superfluous. Instead, we simply swap 0 and -1 arguments of the
> preceding "vsel".
>
> gcc/testsuite/ChangeLog:
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.
> *
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
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
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
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 -
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
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.
> *
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 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
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 tes
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.
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
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
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.
>
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
This works around a limitation of gcse with handling of partially
clobbered registers. With this patch our GOT pointer register r12 is
not marked as partially clobbered anymore for the -m31 -mzarch -fpic
combination. This is correct since all the bits in r12 we actually
care about are in fact
After adding vec_cmp expanders we have seen various performance
related regression in the testsuite. These appear to be caused by a
missing vcond_mask definition in the backend. Fixed with this patch.
The patch fixes the following testsuite fails:
FAIL: gcc.dg/vect/vect-21.c -flto
The S/390 backend does not define vec_cmp expanders so far. We relied
solely on expanding vcond. With commit 502d63b6d various testcases
started to ICE now.
This patch just adds the missing expanders to prevent the ICE.
However, there are still a couple of performance-related testcase
decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.
Bootstrapped and regression tested on IBM Z.
Committed to head, gcc-10, gcc-9, and gcc-8 branches.
gcc/ChangeLog:
PR rtl-optimization/97439
* dfp.c (decimal_real_maxval): Set the sign flag in the
On 18.10.20 20:32, Stefan Schulze Frielinghaus wrote:
> 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
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 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
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
---
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
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 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 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
For the testcase a symbol with a TLS reloc and an unary minus is being
generated. The backend didn't handle this correctly.
In s390_cannot_force_const_mem an unary minus on a symbolic constant
is rejected now since gas would not allow this.
legitimize_tls_address now makes the NEG rtx the
The testcase failed because our backend refuses to generate vector
compare instructions for signaling operators with -fno-trapping-math
-fno-finite-math-only.
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
PR target/96456
* config/s390/s390.h
In s390_expand_insv the movstrict patterns are always generated with a
CC clobber although only movstricthi actually needs one. The patch
invokes the expanders instead of constructing the pattern by hand.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
On 09.07.20 09:29, Stefan Schulze Frielinghaus wrote:
> 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.
> *
On 09.07.20 09:35, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390x with and without a patched gas. Ok
> for master?
>
> gcc/ChangeLog:
>
> * config.in: Regenerate.
> * config/s390/s390.c (print_operand): Emit vector alignment hints
> for target z13, if
On 15.07.20 17:53, Stefan Schulze Frielinghaus wrote:
> 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.
> *
On 15.07.20 17:53, Stefan Schulze Frielinghaus wrote:
> From: Andreas Krebbel
>
> The IBM z14 POP adds an optional alignment operand to the vl, vst,
> vlm, and vstm instruction (vector loads and stores). Vectors residing
> on 8 or 16 byte boundaries might get loaded or stored
On 01.07.20 14:29, Ilya Leoshkevich wrote:
...
> gcc/ChangeLog:
>
> 2020-06-30 Ilya Leoshkevich
>
> * config/s390/s390.h (CODE_LABEL_BOUNDARY): Specify that s390
> requires code labels to be aligned on a 2-byte boundary.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-30 Ilya
on IBM z15.
Committed to mainline.
2020-06-17 Andreas Krebbel
gcc/
* config/s390/s390.c (s390_fix_long_loop_prediction): Exit early
for PARALLELs.
gcc/testsuite/
* gcc.target/s390/20200617.c: New test.
---
gcc/config/s390/s390.c | 9 +++--
gcc
On 16.06.20 10:26, Stefan Schulze Frielinghaus wrote:
> Since 87cb9423add vector alignment hints are emitted for target z13,
> too. This patch changes this behaviour in the sense that alignment
> hints are only emitted for target z13 if the assembler accepts them.
>
> Bootstrapped and regtested
On 28.05.20 20:24, Stefan Schulze Frielinghaus wrote:
> Vector alignment hints are fully supported since z14. On z13 alignment
> hints have no effect, however, instructions with alignment hints are
> still legal. Thus, emit alignment hints also for z13 targets so that if
> the binary is actually
Probes emitted by the common code routines still use a store. Define
the "probe_stack" pattern to use a compare instead.
Bootstrapped and regression tested on s390x
Committed to mainline
gcc/ChangeLog:
2020-05-14 Andreas Krebbel
* config/s390/s390.c (s390_emit_stack_pr
-05-14 Andreas Krebbel
* config/s390/s390.c (allocate_stack_space): Add missing updates
of last_probe_offset.
gcc/testsuite/ChangeLog:
2020-05-14 Andreas Krebbel
* gcc.target/s390/stack-clash-1.c: New test.
---
gcc/ChangeLog | 5
2020-05-08 Andreas Krebbel
* explow.c (anti_adjust_stack_and_probe_stack_clash): Remove
prototype. Remove static.
* explow.h (anti_adjust_stack_and_probe_stack_clash): Add
prototype.
* config/s390/s390.md ("allocat
On 04.05.20 09:27, Richard Biener wrote:
> On Mon, May 4, 2020 at 8:14 AM Andreas Krebbel wrote:
>>
>> On 30.04.20 18:33, Richard Biener wrote:
>>> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel
>>> wrote:
>>>>
>>>> On 30.04.20 08:25, R
On 30.04.20 18:33, Richard Biener wrote:
> On Thu, Apr 30, 2020 at 5:14 PM Andreas Krebbel wrote:
>>
>> On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
>>> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote:
>>>>
>>>> On Tue, 2020-04-28 at 1
On 30.04.20 08:25, Richard Biener via Gcc-patches wrote:
> On Wed, Apr 29, 2020 at 5:56 PM Jeff Law wrote:
>>
>> On Tue, 2020-04-28 at 11:44 +0200, Richard Biener via Gcc-patches wrote:
>>>
>>> Btw, does s390 have different inlining parameters somehow?
>> I think so. We saw a ton of backend
On 28.04.20 17:44, Jakub Jelinek wrote:
> On Tue, Apr 28, 2020 at 04:23:24PM +0200, Andreas Krebbel via Gcc-patches
> wrote:
>> Given that this is something which hasn't been covered by the ABI so far I'm
>> not sure we really need
>> a -Wpsabi warning for that.
>
load the full vector. If it can be
recognized that it is in effect a full vector register load or store
it is now implemented with vl/vst instead.
I'll commit it to mainline after successful bootstrap and regtest.
gcc/ChangeLog:
2020-04-29 Andreas Krebbel
* config/s390/constraints.md
On 28.04.20 14:13, Jakub Jelinek wrote:
> Hi!
>
> So, based on the yesterday's discussions, similarly to powerpc64le-linux
> I've done some testing for s390x-linux too.
>
> First of all, I found a bug in my patch from yesterday, it was printing
> the wrong type like 'double' etc. rather than the
On 27.04.20 09:36, Jakub Jelinek wrote:
> On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote:
>> Ok. Thanks for doing this!
>
> Thanks, committed.
>
>> We probably have to look into providing a -Wpsabi warning as well.
>
> So like this? Untes
On 26.04.20 14:20, Jakub Jelinek wrote:
> Hi!
>
> The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
> on s390x-linux.
>
> Bootstrapped/regtested on s390x-linux without and with the patch, the
> difference being:
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032
On 22.04.20 13:56, Stefan Schulze Frielinghaus wrote:
> Hi,
>
> Added option `--save-temps` back to `addsub-signed-overflow-{1,2}.c`.
> Ok for master?
>
> Cheers,
> Stefan
>
> gcc/ChangeLog:
>
> 2020-04-21 Stefan Schulze Frielinghaus
>
> * config/s390/s390.md ("*_ior_and_sr_ze"):
-04-20 Andreas Krebbel
* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.
gcc/testsuite/ChangeLog:
2020-04-20 Andreas Krebbel
* g++.dg/pr94666.C: New test.
---
gcc/ChangeLog
point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!
Bootstrapped and regression-tested on IBM z15.
gcc/ChangeLog:
2020-04-17 Andreas Krebbel
PR target/94613
On 07.04.20 18:26, Iain Buclaw wrote:
>
>
> On 07/04/2020 16:33, Stefan Liebler wrote:
>> On 4/1/20 6:20 PM, Stefan Liebler wrote:
>>> On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
>
Hi Stefan,
As I've already
On 07.04.20 09:59, Iain Buclaw wrote:
> On 01/04/2020 18:20, Stefan Liebler wrote:
>> On 4/1/20 12:54 PM, Iain Buclaw wrote:
>>> On 01/04/2020 08:28, Stefan Liebler wrote:
ping
>>>
>>> Thanks, I'll send the patch upstream, as it's the same there.
>>>
>>> Looks OK to me.
>>>
>>> Regards
From: Jim Johnston
Check for and handle new skip trace addresses when unwinding on zTPF.
libgcc/ChangeLog:
2020-04-03 Jim Johnston
* config/s390/tpf-unwind.h (MIN_PATRANGE, MAX_PATRANGE)
(TPFRA_OFFSET): Macros removed.
(CP_CNF, cinfc_fast, CINFC_CMRESET,
modifier was plain
wrong: "sub3" and "ior_not3". Fortunately it never had any effect.
Bootstrapped and regression tested on s390x.
SPEC binaries built with and without the patch are identical.
gcc/ChangeLog:
2020-04-02 Andreas Krebbel
* config/s390/vect
On 3/6/20 10:15 AM, Ville Voutilainen wrote:
> On Fri, 6 Mar 2020 at 10:41, Andreas Krebbel wrote:
>>
>> zTPF uses the same numeric value for ENOSYS and ENOTSUP.
>>
>> Ok for mainline?
>>
>> libstdc++-v3/ChangeLog:
>>
>> 2020-03-06 Andreas
gcc/ChangeLog:
2020-03-06 Andreas Krebbel
* config/s390/s390.md ("tabort"): Get rid of two consecutive
blanks in format string.
---
gcc/config/s390/s390.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/s390.md b/gcc/config
zTPF uses the same numeric value for ENOSYS and ENOTSUP.
Ok for mainline?
libstdc++-v3/ChangeLog:
2020-03-06 Andreas Krebbel
* src/c++11/system_error.cc: Omit the ENOTSUP case statement if it
would match ENOSYS.
---
libstdc++-v3/src/c++11/system_error.cc | 3 ++-
1 file
On 3/5/20 12:34 AM, Joseph Myers wrote:
> On Wed, 4 Mar 2020, Andreas Krebbel wrote:
>
>> Building a zTPF cross currently fails when building libstdc++
>> complaining about the __UINTPTR_TYPE__ to be missing.
>>
>> Fixed by including the glibc-stdint.h header.
Building a zTPF cross currently fails when building libstdc++
complaining about the __UINTPTR_TYPE__ to be missing.
Fixed by including the glibc-stdint.h header.
2020-03-04 Andreas Krebbel
* config.gcc: Include the glibc-stdint.h header for zTPF.
---
gcc/config.gcc | 2 +-
1 file
be changed at compile-time using
the new command line options. For convenience one additional command
line option (-mtpf-trace-skip) implements a new set of hard-coded
addresses.
gcc/ChangeLog:
2020-03-04 Andreas Krebbel
* config/s390/s390.c (s390_emit_prologue): Specify the 2 new
For the zTPF we must not use floating point registers.
gcc/ChangeLog:
2020-03-04 Andreas Krebbel
* config/s390/s390.c (s390_secondary_memory_needed): Disallow
direct FPR-GPR copies.
(s390_register_info_gprtofpr): Disallow GPR content to be saved in
FPRs
libgcc is supposed to be built with the trace skip flags and branch
targets. Add a zTPF header file fragment and add the -mtpf-trace-skip
option.
libgcc/ChangeLog:
2020-03-04 Andreas Krebbel
* config.host: Include the new makefile fragment.
* config/s390/t-tpf: New file
On 2/25/20 10:20 AM, Jakub Jelinek wrote:
> Hi!
>
> In Fedora we configure GCC with --with-arch=zEC12 --with-tune=z13 right now
> and furthermore redhat-rpm-config adds to rpm packages -march=zEC12 -mtune=z13
> options (among others). While looking at the git compilation, I've been
> surprised
On 2/1/20 9:41 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase started to ICE when .POPCOUNT matching has been added
> to match.pd; we had __builtin_popcount*, but nothing would use the
> popcounthi2 expander before.
>
> The problem is that the popcounthi2_z196 expander doesn't emit
on x86_64 by changing the inlining
threshold using: --param max-inline-insns-auto=80
Bootstrapped and regression tested on x86_64 and IBM Z.
Ok for mainline?
libcpp/ChangeLog:
2019-12-17 Andreas Krebbel
PR tree-optimization/92176
* mkdeps.c (deps_add_default_target):
---
libcpp
The backend emits 16 bit memory loads for single element character
vector. As a result the character will not be right justified in the
GPR.
gcc/ChangeLog:
2019-12-16 Andreas Krebbel
PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
On 15.11.19 19:58, Szabolcs Nagy wrote:
> On 15/11/2019 18:15, Segher Boessenkool wrote:
>> On Fri, Nov 15, 2019 at 06:03:25PM +, Szabolcs Nagy wrote:
>>> i'm fine with that, it means the --with-long-double-128
>>> switch does not work on *-musl,
>>
>> I thought that is what you wanted to do.
On 15.11.19 18:23, Szabolcs Nagy wrote:
> Add the musl dynamic linker names.
>
> Build tested on s390x-linux-musl and s390x-linux-gnu.
>
> gcc/ChangeLog:
>
> 2019-11-15 Szabolcs Nagy
>
> * config/s390/linux.h (MUSL_DYNAMIC_LINKER32): Define.
> (MUSL_DYNAMIC_LINKER64): Define.
>
On 11.11.19 15:39, Richard Henderson wrote:
> On 11/7/19 12:52 PM, Andreas Krebbel wrote:
>> +; Such patterns get directly emitted by noce_emit_store_flag.
>> +(define_insn_and_split "*cstorecc_z13"
>> + [(set (match_o
of a CC compare into a GPR.
Done with the attached patch.
Bootstrapped and regression tested on s390x.
Committed to mainline.
2019-11-07 Andreas Krebbel
* config/s390/s390.md ("*cstorecc_z13"): New insn_and_split
pattern.
gcc/testsuite/ChangeLog:
2019-11-07 Andre
These tests check if loop peeling has been applied to avoid
having to vectorize unaligned loops. On Z we do not have any
alignment requirements for vectorization so we also don't need want
the loop peeling here.
2019-11-05 Andreas Krebbel
* gcc.dg/tree-ssa/gen-vect-26.c: Disable loop
actually is a pity.
The patch sets min-vect-loop-bound back to the default value of 0 in
order to enable vectorization.
2019-11-05 Andreas Krebbel
* gcc.dg/tree-ssa/gen-vect-11.c: Add --param min-vect-loop-bound=0
for IBM Z.
* gcc.dg/tree-ssa/gen-vect-11.c: Likewise
This fixes an ICE in gcc.dg/attr-vector_size.c testcase.
gcc/ChangeLog:
2019-11-05 Andreas Krebbel
* config/s390/s390.c (s390_vector_alignment): Check if the value
fits into uhwi before using it.
---
gcc/config/s390/s390.c | 8 +++-
1 file changed, 7 insertions(+), 1
/ChangeLog:
2019-11-05 Andreas Krebbel
* gcc.target/s390/s390.exp
(check_effective_target_s390_useable_hw): Add inline asm for z14
and z15. Replace instruction for z13 with lochiz. Add register
clobbers. Check also for __zarch__ when doing the __VX__ test.
---
gcc
Andreas Krebbel (4):
IBM Z: Use tree_fits_uhwi_p in vector_alignment hook
IBM Z: Fix testsuite useable_hw check
IBM Z: gen-vect-11/32: Set min-vect-loop-bound param back to default
IBM Z: gen-vect-26/28: Vectorizing without peeling is ok for Z
gcc/config/s390/s390.c
Andreas Krebbel
* gcc.dg/ipa/ipa-sra-19.c: Remove dg-skip-if. Add argument type to
prototype of k.
---
gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/ipa/ipa-sra-19.c
b/gcc/testsuite/gcc.dg/ipa/ipa
On 24.10.19 15:26, Martin Jambor wrote:
> Hi,
>
> On Thu, Oct 24 2019, Andreas Krebbel wrote:
>> On 02.10.19 17:06, Martin Jambor wrote:
>>> Hi,
>>>
>>> I seem to remember I minimized gcc.dg/ipa/ipa-sra-19.c on power but
>>> perhaps I am wron
On 02.10.19 17:06, Martin Jambor wrote:
> Hi,
>
> I seem to remember I minimized gcc.dg/ipa/ipa-sra-19.c on power but
> perhaps I am wrong because the testcase fails there with a
> power-specific error:
>
> gcc.dg/ipa/ipa-sra-19.c:19:3: error: AltiVec argument passed to unprototyped
> function
On 23.10.19 13:02, Ilya Leoshkevich wrote:
> Boostrapped and regtested on s390x-redhat-linux.
>
> gcc/ChangeLog:
>
> 2019-10-21 Ilya Leoshkevich
>
> * config/s390/s390.c (s390_get_thread_pointer): Use
> gen_get_thread_pointer.
> (s390_expand_split_stack_prologue): Likewise.
On 11.10.19 18:35, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.
>
> gcc/ChangeLog:
>
> 2019-10-10 Ilya Leoshkevich
>
> * config/s390/s390.md: Run %a0:DI splitters only after reload.
>
> gcc/testsuite/ChangeLog:
>
> 2019-10-10 Ilya Leoshkevich
>
>
Since the update to Go 1.13beta1 the kdsaQuery function is expected to
be present. However, it is not with GCCGO since the assembler file
from GOLANG cannot be understood by gas. This patch adds an inline
assembly implementation to cpu_gccgo.c.
2019-10-14 Andreas Krebbel
* libgo/go
2019-10-14 Andreas Krebbel
* libgo/go/runtime/os_linux_s390x.go: cpu.go, cpu_s390x.go,
cpu.go, and cpu_linux_s390x.go expect the hardware facilities in
capital letters. Sync this file accordingly. Add support for the
VXE HWCAP as well.
---
libgo/go/runtime
this I could also get rid of the unspec which was required for
the parameter block generation so far.
gcc/ChangeLog:
2019-10-10 Andreas Krebbel
PR target/91035
* config/s390/s390-protos.h (s390_output_split_stack_data): Add
prototype.
* config/s390/s390.md
So far z15 was identified as arch13. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
2019-10-10 Andreas Krebbel
* common/config/s390/s390-common.c (PF_ARCH13): Rename to...
(PF_Z15): ... this.
* config.gcc: Add z15 as option
On 01.10.19 15:27, wrote:
> gcc/testsuite/ChangeLog:
>
> 2019-08-09 Ilya Leoshkevich
>
> PR target/77918
> * gcc.target/s390/s390.exp: Enable Fortran tests.
> * gcc.target/s390/zvector/autovec-double-quiet-eq.c: New test.
> *
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> dg-torture.exp=inf-compare-1.c is failing, because (qNaN > +Inf)
> comparison is compiled to CDB instruction, which does not signal an
> invalid operation exception. KDB should have been used instead.
>
> This patch introduces a new CCmode and a new
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> z13 supports only non-signaling vector comparisons. This means we
> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
> middle-end about this by using more restrictive operator predicate in
> vcond.
>
> gcc/ChangeLog:
>
>
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> s390.md uses a lot of near-identical expanders that perform dispatching
> to other expanders based on operand types. Since the following patch
> would require even more of these, avoid copy-pasting the code by
> generating these expanders using an
On 01.10.19 15:27, Ilya Leoshkevich wrote:
> Currently gcc does not emit wf{c,k}* instructions when comparing long
> double values. Middle-end actually adds them in the first place, but
> then veclower pass replaces them with floating point register pair
> operations, because the corresponding
On 05.09.19 13:10, Ilya Leoshkevich wrote:
> Currently gcc does not emit wf{c,k}* instructions when comparing long
> double values. Middle-end actually adds them in the first place, but
> then veclower pass replaces them with floating point register pair
> operations, because the corresponding
On 05.09.19 13:10, Ilya Leoshkevich wrote:
> s390.md uses a lot of near-identical expanders that perform dispatching
> to other expanders based on operand types. Since the following patch
> would require even more of these, avoid copy-pasting the code by
> generating these expanders using an
On 05.09.19 13:10, Ilya Leoshkevich wrote:
> vec_unordered is vec_ordered plus a negation at the end.
> Reuse vec_unordered logic.
>
> gcc/ChangeLog:
>
> 2019-08-13 Ilya Leoshkevich
>
> PR target/77918
> * config/s390/vector.md (vec_unordered): Call
> gen_vec_ordered.
Ok.
On 06.09.19 12:48, Richard Biener wrote:
> On Fri, Sep 6, 2019 at 10:11 AM Andreas Krebbel wrote:
>>
>> Hi,
>>
>> since this caused a critical performance regression in the OpenJ9 byte code
>> interpreter after
>> migrating from GCC 4.8 to GCC 7 I
d3dc20418aad41af83fe45ccba527deb0b334983
Author: krebbel
Date: Thu Jun 6 11:35:04 2019 +
Fix PR88751
This patch implements a small improvement for the heuristic in lra
which decides when it has to activate the simpler register allocation
algorithm.
gcc/ChangeLog:
2019-06-06 Andreas Krebbel
On 02.09.19 16:46, Ilya Leoshkevich wrote:
> Bootstrap and regtest running on s390x-redhat-linux.
>
> The new sigfpe-eh.c fails with
>
> internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have
> 'w' (rtx const_int)
>
> This is most likely due to a typo: XEXP (*op1, 0) was
This patch implements the addv, subv, and mulv patterns for signed
integers.
Bootstrapped and regression tested on s390x (IBM z14).
Committed to mainline.
gcc/ChangeLog:
2019-07-24 Andreas Krebbel
* config/s390/predicates.md (addv_const_operand): New predicate.
* config
201 - 300 of 1046 matches
Mail list logo
