On Thu, Jul 31, 2025 at 04:31:14PM +0200, Jens Remus wrote:
> Hello Stefan!
>
> On 7/10/2025 4:16 PM, Stefan Schulze Frielinghaus wrote:
> > So far only a per thread canary in the TLS block is supported. This
> > patch adds support for a global canary, too. For this the n
This is follow-up to
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/691000.html
-- >8 --
From: Stefan Schulze Frielinghaus
Hard register constraints are only supported for LRA and not old reload.
Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA which is
why these tests f
On Tue, Jul 29, 2025 at 11:26:40PM +0200, Georg-Johann Lay wrote:
> Am 29.07.25 um 15:56 schrieb Stefan Schulze Frielinghaus:
> > From: Stefan Schulze Frielinghaus
> >
> > Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA. Since old
> > reload pass is still
On Tue, Jul 29, 2025 at 02:36:28PM -0700, Andrew Pinski wrote:
> On Tue, Jul 29, 2025 at 6:58 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > From: Stefan Schulze Frielinghaus
> >
> > Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA. Since old
>
From: Stefan Schulze Frielinghaus
Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA. Since old
reload pass is still used, add option -mlra for those targets.
For hppa, register 0 cannot be used as a general register. Therefore,
use temporary registers r20 and r21 instead.
gcc
On Mon, Jul 28, 2025 at 11:11:17AM +0200, Georg-Johann Lay wrote:
> Am 09.07.25 um 15:48 schrieb Stefan Schulze Frielinghaus:
> > This is a follow-up to
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html
> >
> > I added the last missing pieces namely c
On Thu, Jul 24, 2025 at 12:03:43PM +0200, Stefan Schulze Frielinghaus wrote:
> It looks like we didn't have a test so far reaching this point which
> changed with the new hard register constraint tests. Bootstrap and
> regtest are still running on x86_64. If they succeed, o
Also consider target x86_64 -m32.
gcc/testsuite/ChangeLog:
PR target/121205
* gcc.dg/asm-hard-reg-1.c: Also consider target x86_64 -m32.
* gcc.dg/asm-hard-reg-2.c: Ditto.
* gcc.dg/asm-hard-reg-4.c: Ditto.
* gcc.dg/asm-hard-reg-5.c: Ditto.
* gcc.dg/a
It looks like we didn't have a test so far reaching this point which
changed with the new hard register constraint tests. Bootstrap and
regtest are still running on x86_64. If they succeed, ok for mainline?
-- >8 --
As noted by Sam in the PR, with checking enabled tests
gcc.target/i386/asm-hard
Thanks for confirmation! Here is the updated patch which I'm about to
commit once the final bootstrap on s390x succeeds. Cross compiler is
green for gcc.dg/asm-hard-reg-error-{4,5}.c on sparc*-sun-solaris2.11.
-- >8 --
Tests gcc.dg/asm-hard-reg-error-{4,5}.c ICE on sparc*-sun-solaris2.11
since
Tests gcc.dg/asm-hard-reg-error-{4,5}.c ICE on sparc*-sun-solaris2.11
since in tm-preds.h we have
#define CONSTRAINT_LEN(c_,s_) 1
and, therefore, do not parse hard register constraints correctly.
Hard register constraints are non-single character constraints and
require insn_constraint_len() in
On Mon, Jul 21, 2025 at 01:54:55PM -0700, H.J. Lu wrote:
> On Mon, Jul 21, 2025 at 4:16 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote:
> > >
> > >
> > > On 7/17/25 2:24 AM, Stefan Schulze Fri
Bootstrapped successfully on s390x and tests dg.exp=asm-hard-reg-\*.c
and s390.exp=asm-hard-reg-\*.c are successful, too. Ok for mainline?
-- >8 --
The GNU extension rawmemchr cannot be used. Therefore, replace it by a
simple loop.
gcc/ChangeLog:
* genpreds.cc (write_insn_constraint_l
On Mon, Jul 21, 2025 at 11:03:08PM +0800, Xi Ruoyao wrote:
> On Mon, 2025-07-21 at 16:57 +0200, Stefan Schulze Frielinghaus wrote:
> > The generated file tm-preds.h contains now:
> >
> > static inline size_t
> > insn_constraint_len (char fc, const char *str)
> >
may be included easily here, too.
If the dependency to string.h is not wanted, I could also come up with a
simple loop.
Sorry for the inconvenience.
Cheers,
Stefan
> Thanks,
> Sangamesh
>
> On Mon, Jul 21, 2025 at 4:46 PM Stefan Schulze Frielinghaus <
> stefa...@linux.ibm.com&
On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote:
>
>
> On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote:
> > On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
> > > This is a follow-up to
> > > https://gcc.gnu.org/pipe
Added changelog entries.
-- >8 --
If a check-function-bodies test is compiled using -fstack-protector*,
-fhardened, -fstack-check*, or -fstack-clash-protection, but the test is
not asking explicitly for those via dg-options or
dg-additional-options, then mark the test as unsupported. Since these
Currently for a signbit operation instructions tc{f,d,x}b + ipm + srl
are emitted. If the source operand is a MEM, then a load precedes the
sequence. A faster implementation is by issuing a load either from a
REG or MEM into a GPR followed by a shift.
In spirit of the signbit function of the C s
Exploit the fact that instruction VLGV zeros excessive bits of a GPR.
gcc/ChangeLog:
* config/s390/vector.md (bhfgq): Add scalar modes.
(*movdi_zero_extend_A): New insn.
(*movsi_zero_extend_A): New insn.
(*movdi_zero_extend_B): New insn.
(*movsi_zero_extend
Moving between GPRs and VRs in any mode with size less than or equal to
8 bytes becomes available with vector extensions. Without adapting
costs for those loads, we typically go over memory.
gcc/ChangeLog:
* config/s390/s390.cc (s390_register_move_cost): Add costing for
vlvg/vlgv
On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to
> https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html
>
> I added the last missing pieces namely changelogs, and bootstrapped and
> regtested on
>
> aarc
gcc/ChangeLog:
PR target/117015
* config/s390/s390-protos.h (s390_expand_int_spaceship): New
function.
(s390_expand_fp_spaceship): New function.
* config/s390/s390.cc (s390_expand_int_spaceship): New function.
(s390_expand_fp_spaceship): New function
During jump bypassing also consider insns of the form
(insn 25 57 26 9 (parallel [
(set (reg:CCZ 33 %cc)
(compare:CCZ (reg:SI 60 [ _9 ])
(const_int 0 [0])))
(clobber (scratch:SI))
]) "spaceship-fp-4.c":27:1 1746 {*tstsi_cconly_ext
On Thu, Jul 10, 2025 at 09:14:23AM +0200, Juergen Christ wrote:
> The default setting of s390 for the parameter min-vect-loop-bound was
> set to 2 to prevent certain epilogue loop vectorizations in the past.
> Reevaluation of this parameter shows that this setting now is not
> needed anymore and so
On Thu, Jul 10, 2025 at 09:14:24AM +0200, Juergen Christ wrote:
> Implementation and tests for the standard reduction optabs.
>
> Bootstrapped and regtested on s390. Ok for trunk?
>
> Signed-off-by: Juergen Christ
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (reduc_plus_scal_): Implem
So far only a per thread canary in the TLS block is supported. This
patch adds support for a global canary, too. For this the new option
-mstack-protector-guard={global,tls} is added which defaults to tls.
The global canary is expected at symbol __stack_chk_guard which means
for a function prolo
This implements error handling for hard register constraints including
potential conflicts with register asm operands.
In contrast to register asm operands, hard register constraints allow
more than just one register per operand. Even more than just one
register per alternative. For example, a v
Implement hard register constraints of the form {regname} where regname
must be a valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions. A more verbose description is given in extend.texi.
It is expected a
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
sufficient since
I need to consider more corner cases. Therefore, I would
like to spend some more time on this before I push this new feature.
In total no huge changes. Still ok for mainline?
Stefan Schulze Frielinghaus (3):
Hard register constraints
Error handling for hard register constraints
genoutput: Ve
Computing the address of the thread pointer on s390 involves multiple
instructions and therefore bears the risk that the address of the canary
or intermediate values of it are spilled after prologue in order to be
reloaded for the epilogue. Since there exists no mechanism to ensure
that a value is
On Mon, Jul 07, 2025 at 01:06:44PM +0200, Juergen Christ wrote:
> Done. Should I send a v3?
If bootstrapped and the new tests are still successful (no need for a
full testsuite run I guess), then feel free to push immediately.
On Wed, Jun 25, 2025 at 10:04:49AM +0200, Juergen Christ wrote:
> Some patterns that are detected by the autovectorizer can be supported by
> s390. Add expanders such that autovectorization of these patterns works.
>
> RTL for the builtins used unspec to represent highpart multiplication.
> Repla
On Wed, Jun 25, 2025 at 10:04:41AM +0200, Juergen Christ wrote:
> On VXE targets, we can directly use the fp min/max instruction instead of
> calling into libm for fmin/fmax etc.
>
> Provide fmin/fmax versions also for vectors even though it cannot be
> called directly. This will be exploited wit
From: Stefan Schulze Frielinghaus
My understand is that during check_compile compiler_flags contains all
the options passed to gcc and current_compiler_flags contains options
passed via dg-options and dg-additional-options. I did a couple of
experiments and printf-style debugging which endorsed
On Tue, Jul 01, 2025 at 06:33:12PM +0200, Jakub Jelinek wrote:
> On Tue, Jul 01, 2025 at 03:47:53PM +0200, Stefan Schulze Frielinghaus wrote:
> > In the past years I have started to use more and more function body
> > checks whenever gcc emits optimal code for a function. With th
Hi Jakub,
On Tue, Jul 01, 2025 at 02:50:04PM +0200, Jakub Jelinek wrote:
> Hi!
>
> In Fedora/RHEL we usually test with
> make check RUNTESTFLAGS="--target_board=unix/'{,-fstack-protector-strong}'"
> because -fstack-protector-strong is used when building pretty much all the
> packages.
>
> In the
On Sat, Jun 21, 2025 at 09:18:43AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > This implements error handling for hard register constraints including
> > potential conflicts with register asm operands.
> >
> > In
On Mon, Jun 23, 2025 at 07:12:58PM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Currently a register asm already materializes during expand. This
> > means, a hard register is allocated for the very first access of a
> >
On Sat, Jun 21, 2025 at 09:06:42AM -0600, Jeff Law wrote:
>
>
> On 5/20/25 1:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may be
>
On Fri, Jun 20, 2025 at 10:17:20AM -0400, Vladimir Makarov wrote:
>
> On 5/20/25 3:22 AM, Stefan Schulze Frielinghaus wrote:
> > Implement hard register constraints of the form {regname} where regname
> > must be a valid register name for the target. Such constraints may
On Mon, Jan 20, 2025 at 02:59:44PM +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote:
> > On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus
> > wrote:
> > >
> > > gcc/ChangeLog:
> >
> &
On Tue, Jun 24, 2025 at 09:49:01AM +0200, Juergen Christ wrote:
> Some patterns that are detected by the autovectorizer can be supported by
> s390. Add expanders such that autovectorization of these patterns works.
>
> Bootstrapped and regtested on s390. Ok for trunk?
>
> gcc/ChangeLog:
>
>
On Fri, Jun 20, 2025 at 08:23:01PM +0200, Juergen Christ wrote:
> Also provide the vec_extract patterns for floats on pre-z13 machines
> to prevent ICEing in those cases.
>
> Bootstrapped and regtested on s390.
Ok.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (VF): Don'
On Mon, Jun 23, 2025 at 09:51:13AM +0200, Juergen Christ wrote:
> On VXE targets, we can directly use the fp min/max instruction instead of
> calling into libm for fmin/fmax etc.
>
> Provide fmin/fmax versions also for vectors even though it cannot be
> called directly. This will be exploited wit
Ping
On Tue, May 20, 2025 at 09:22:55AM +0200, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672941.html
> with basically the only change of adding more tests like for aarch64 and
> the y constraint or for i386 and
On Wed, Jun 04, 2025 at 09:12:58AM +0100, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, Jun 4, 2025 at 7:28 AM H.J. Lu wrote:
> >>
> >> On s390x, for input:
> >>
> >> (call_insn/u 7 6 11 2 (parallel [
> >> (set (reg:SI 2 %r2)
> >> (call (subreg:QI (symb
On Wed, Jun 04, 2025 at 05:07:13PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 04, 2025 at 05:02:45PM +0200, Stefan Schulze Frielinghaus wrote:
> > Building a subreg in case of
> >
> > else if (GET_CODE (x) == CONST)
> > {
> > /* Extract the symb
On Mon, May 26, 2025 at 12:17:44PM +0200, Juergen Christ wrote:
> Since floating point and vector registers overlap on s390, more
> efficient code can be generated to extract FPRs from VRs.
> Additionally, for double vectors, more efficient code can be generated
> to load specific lanes.
>
> Boots
On Wed, May 21, 2025 at 07:34:27PM +0200, Stefan Schulze Frielinghaus wrote:
> libstdc++-v3/ChangeLog:
>
> * testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
> ---
> Ok for mainline?
Just realized that I can use my super powers ;-) and pushed as ob
libstdc++-v3/ChangeLog:
* testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
---
Ok for mainline?
libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
b/libstdc++-v
This implements error handling for hard register constraints including
potential conflicts with register asm operands.
In contrast to register asm operands, hard register constraints allow
more than just one register per operand. Even more than just one
register per alternative. For example, a v
Since genoutput has no information about hard register names we cannot
statically verify those names in constraints of the machine description.
Therefore, we have to do it at runtime. Although verification shouldn't
be too expensive, restrict it to checking builds. This should be
sufficient since
Currently a register asm already materializes during expand. This
means, a hard register is allocated for the very first access of a
register asm as e.g. in an assignment. As a consequence this might lead
to suboptimal register allocation if the assignment and the using asm
statement are spread f
Implement hard register constraints of the form {regname} where regname
must be a valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions.
It is expected and desired that optimizations coalesce multiple pseud
ack whether the implementation of hard register
constraints is sensible at all or whether I should drop this patch.
Cheers,
Stefan
Stefan Schulze Frielinghaus (4):
Hard register constraints
Error handling for hard register constraints
genoutput: Verify hard register constraints
Rewrite register asm int
On Wed, May 14, 2025 at 04:30:35PM +0200, Juergen Christ wrote:
> Since floating point and vector registers overlap on s390, more
> efficient code can be generated to extract FPRs from VRs.
> Additionally, for double vectors, more efficient code can be generated
> to load specific lanes.
>
> gcc/C
Insn tf_to_fprx2 moves a TF value into a floating-point register pair.
For alternative 0, the input is a vector register, however, in the else
case instruction ldr is emitted which expects floating-point register
operands only. Thus, this works only for vector registers which overlap
with floating
For target VXE3 just emit a 128-bit comparison followed by a conditional
load. For targets prior VXE3, emulate the 128-bit comparison and make
use of a conditional load, too.
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_expand_cstoreti4): New
function.
* config/s390/s
---
htdocs/gcc-15/changes.html | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index f112af58..d851a744 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -1295,7 +1295,28 @
On Fri, Apr 25, 2025 at 01:21:46PM +0200, Jakub Jelinek wrote:
> Hi!
>
> Here is a patch to handle the PARALLEL case too.
> I think we can just use rtx_equal_p there, because it will always use
> SImode in the EXPR_LIST REGs in that case.
>
> Bootstrapped/regtested on s390x-linux, ok for trunk an
On Thu, Apr 24, 2025 at 12:49:39PM +0200, Jakub Jelinek wrote:
> On Thu, Apr 24, 2025 at 09:44:45AM +0200, Stefan Schulze Frielinghaus wrote:
> > Yes, every parameter is sign or zero extended if its type is smaller
> > than 64bit.
>
> > Note, on s390 a parameter is eit
On Wed, Apr 23, 2025 at 04:46:17PM +0200, Jakub Jelinek wrote:
[...]
> > > It won't really work at -O0 but should work for -O1 and above, at least
> > > when
> > > one doesn't really try to modify the parameter conditionally and hope it
> > > will
> > > be optimized away in the end.
> >
> > It a
Hi Jakub,
On Tue, Apr 22, 2025 at 10:41:29AM +0200, Jakub Jelinek wrote:
> Hi!
>
> protobuf (and therefore firefox too) currently doesn't build on s390*-linux.
> The problem is that it uses [[clang::musttail]] attribute heavily, and in
> llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ argu
On Thu, Apr 17, 2025 at 05:08:10AM +0200, Jakub Jelinek wrote:
> On Wed, Apr 16, 2025 at 08:52:17PM +0200, Jakub Jelinek wrote:
> > The following testcase ICEs since r15-1579 (addition of late combiner),
> > because *clrmem_short can't be split.
> > The problem is that the define_insn uses
> >(
gcc/ChangeLog:
* config/s390/s390.cc: Add z17 scheduler description.
* config/s390/s390.h: Ditto.
* config/s390/s390.md: Ditto.
* config/s390/9175.md: New file.
---
gcc/config/s390/9175.md | 316
gcc/config/s390/s390.cc | 3
The recently announced IBM z17 processor implements the architecture
already supported as arch15. This patch adds support for z17 as an
alternative architecture name for arch15.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename arch15 to z17.
* config.gcc: Add z17.
gcc/ChangeLog:
PR target/119235
* config/s390/s390.cc (s390_hard_regno_mode_ok): Accept only
Pmode for registers AP/FP/RA.
---
gcc/config/s390/s390.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
On Wed, Mar 12, 2025 at 12:38:59PM +, Joseph Myers wrote:
> This commit has changed int __attribute__ ((__mode__ (__word__))) on s390
> -m31 from int to long long. That introduces a glibc testsuite failure -
> the glibc testsuite verifies the expected C++ name mangling of various
> types, i
Since r15-3992-g698e0ec89bc096 we optimize x<=y && x>=y to x==y.
Honour signaling NaNs by using option -fsignaling-nans in order to
prevent this.
gcc/testsuite/ChangeLog:
* gcc.target/s390/zvector/autovec-double-signaling-eq-z13.c:
Honour sNaNs.
---
.../gcc.target/s390/zvector/au
Previously we optimized expressions of the form a < 0 ? -1 : 0 to
(signed)a >> 31 during vcond expanding. Since r15-1638-gaac00d09859cc5
this is done in match.pd. The implementation in the back end as well as
in match.pd are basically the same but still distinct. For the tests in
vcond-shift.c t
There exists no .REDUC_PLUS on s390.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-77.c: Skip on s390.
---
gcc/testsuite/gcc.dg/vect/bb-slp-77.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-77.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-7
On Mon, Mar 10, 2025 at 10:15:00AM +0100, Juergen Christ wrote:
> In legitimize_pic_address we create a
> (const (unspec ... UNSPEC_GOTENT))
> in the GOT offset might be >= 4k. However, the
> s390_delegitimize_address does not contain a case for this scenario.
>
> gcc/ChangeLog:
>
> * conf
Currently insn_cost() only considers the source part of a SET.
Implement TARGET_INSN_COST in order to also take the destination into
account. This may make a difference in case of a MEM where the address
is a SYMBOL_REF.
Fixes testsuite/gcc.target/s390/section-anchors.c.
gcc/ChangeLog:
Deprecate support for the ESA/390 architecture which will be eventually
removed, and encourage the usage of the z/Architecture instead.
Furthermore, default for -m31 to -mzarch whereas previously we defaulted
to -mesa.
gcc/ChangeLog:
* config.gcc: Fail in case of option --with-mode=esa.
Giving it a second thought: instead of checking for something we don't
expect, namely a const_wide_int, and bailing out in such a case, rather
check for something we expect, namely a const_int, and bail out if that
is not the case. This should be more robust.
Bootstrap and regtest are still runni
During combine we may end up with
(set (reg:DI 66 [ _6 ])
(ashift:DI (reg:DI 72 [ x ])
(subreg:QI (and:TI (reg:TI 67 [ _1 ])
(const_wide_int 0x0aabf))
15)))
where the shift count operand does not trivia
still in stage3 of LTO profiledbootstrap), ok for trunk?
Ok and thanks again for fixing this so quickly!
Cheers,
Stefan
>
> 2025-01-30 Jakub Jelinek
> Stefan Schulze Frielinghaus
>
> PR target/118696
> * config/s390/vector.md (*vec_cmp
On Sat, Jan 18, 2025 at 09:36:14AM -0700, Jeff Law wrote:
[...]
> > > Do we detect conflicts between a hard register constraint and another
> > > constraint which requires a singleton class? That's going to be an error
> > > I
> > > suspect, but curious if it's handled.
> >
> > That is a good po
gcc/ChangeLog:
* config/s390/s390.cc: Fix arch15 machine string which must not
be empty.
---
gcc/config/s390/s390.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 313f968c87e..86a5f059b85 100644
--- a/gc
On Mon, Jan 20, 2025 at 02:46:40PM +0100, Richard Biener wrote:
> On Mon, Jan 20, 2025 at 11:04 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > gcc/ChangeLog:
>
> Interesting - I can't find anything about these in the PoP (though I can only
> find the one from Ma
Add 128-bit vector shift support. Deprecate vector shift by byte
builtins where the shift amount is not of type unsigned character.
gcc/ChangeLog:
* config/s390/s390-builtins.def: Add 128-bit variants.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s39
gcc/ChangeLog:
* config/s390/s390-builtins.def: Add 128-bit variants.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.cc (s390_expand_vec_compare_cc): Also
consider TI modes for vectors.
* config/s390/vector.md: Enable *vec_cmp e
Add new instruction variants and also extend builtins in order to deal
with 128-bit integer.
gcc/ChangeLog:
* config/s390/s390-builtins.def: Add new instruction variants.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/vecintrin.h: Add new defines.
Add instruction vgem and vector builtins
vec_gen_element_masks_{8,16,32,64,128}.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_gen_element_masks_128): Add.
(s390_vgemb): Add.
(s390_vgemh): Add.
(s390_vgemf): Add.
(s390_vgemg): Add.
(s390_
Add instructions lxa and llxa.
gcc/ChangeLog:
* config/s390/s390.md (*lxa_index): Add.
(*lxa_displacement_index): Add.
(*lxa_index_base): Add.
(*lxa_displacement_index_base): Add.
(*lxab_displacement_index_base): Add.
(*llxa_displacement_index): Add
Add instruction veval and builtin vec_evaluate.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_evaluate): Add.
(s390_veval): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.md (UNSPEC_VEC_VEVAL): Add.
* config/s39
From: Stefan Schulze Frielinghaus
Bump __VEC__ version to 10305 and add 128-bit integer vector types like
`vector __int128` et al. to the zvector extension.
gcc/ChangeLog:
* config/s390/s390-c.cc (rid_int128): New helper function.
(s390_macro_to_expand): Deal with `vector
Reflect latest updates for vec_(load,store)_len(,_r) which means that
all types except character based types are deprecated.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_load_len): Deprecate
some overloads.
(s390_vec_store_len): Deprecate some overloads.
Add instructions bdepg and bextg and corresponding builtins.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_bdepg): Add.
(s390_bextg): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/s390.md (UNSPEC_BDEPG): Add.
(UNSPEC_BE
Add instruction vblend and builtin vec_blend.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_blend): Add.
(s390_vblendb): Add.
(s390_vblendh): Add.
(s390_vblendf): Add.
(s390_vblendg): Add.
(s390_vblendq): Add.
* config/s390/s390-b
For previous architectures emulate operation max/min.
gcc/ChangeLog:
* config/s390/s390-builtins.def: Add 128-bit variants and remove
bool variants.
* config/s390/s390-builtin-types.def: Update accordinly.
* config/s390/s390.md: Emulate min/max for GPR.
* c
gcc/ChangeLog:
* config/s390/vector.md (div3): Add.
(udiv3): Add.
(mod3): Add.
(umod3): Add.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vxe3/vd-1.c: New test.
* gcc.target/s390/vxe3/vd-2.c: New test.
* gcc.target/s390/vxe3/vdl-1.c: New test
From: Stefan Schulze Frielinghaus
gcc/ChangeLog:
* config/s390/vecintrin.h: Sort definitions.
---
gcc/config/s390/vecintrin.h | 229 ++--
1 file changed, 115 insertions(+), 114 deletions(-)
diff --git a/gcc/config/s390/vecintrin.h b/gcc/config/s390
This series prepares for a future architecture. Pushed.
Stefan Schulze Frielinghaus (18):
s390: Stay scalar for TOINTVEC/tointvec
s390: Sort definitions in vecintrin.h
s390: arch15: Prepare for a future architecture
s390: Bump __VEC__ and add 128-bit integer zvector types
s390: arch15
Add vector single element 128-bit integer support utilizing new
instructions vclzq and vctzq. Furthermore, add scalar 64-bit integer
support utilizing new instructions clzg and ctzg. For ctzg, also define
the resulting value if the input operand equals zero.
gcc/ChangeLog:
* config/s390
For previous architectures emulate operation abs.
gcc/ChangeLog:
* config/s390/s390-builtins.def (s390_vec_abs_s128): Add.
(s390_vlpq): Add.
* config/s390/s390-builtin-types.def: Update accordingly.
* config/s390/vector.md (abs2): Emulate w/o VXE3.
(*abs2):
Currently TOINTVEC maps scalar mode TI/TF to vector mode V1TI/V1TF,
respectively. As a consequence we may end up with patterns with a
mixture of scalar and vector modes as e.g. for
(define_insn "vec_sel0"
[(set (match_operand:VT 0 "register_operand" "=v")
(if_then_else:VT
(eq (
From: Stefan Schulze Frielinghaus
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Add arch15 processor flags.
* config.gcc: Add arch15 for options --with-{arch,mtune}.
* config/s390/driver-native.cc (s390_host_detect_local_cpu):
Default to arch15
From: Stefan Schulze Frielinghaus
gcc/ChangeLog:
* config/s390/s390-builtins.def (B_VXE3): Define.
(B_ARCH15): Define.
* config/s390/s390-c.cc (s390_resolve_overloaded_builtin):
Consistency checks for VXE3.
* config/s390/s390.cc (s390_expand_builtin
1 - 100 of 381 matches
Mail list logo
