After r16-2649-g0340177d54d tests fail for
gcc.target/s390/arch13/bitops-{1,2}.c since sign extends in conjunction
with (subreg (not a)) are folded, now. That is, of course, wanted.
Since the original tests were about 32-bit operations, circumvent the
sign extend by not returning a value but rathe
From: Stefan Schulze Frielinghaus
Verify we don't have any vector temporaries in the IL at least until
ISEL which may introduce VEC_EXTRACTs on targets which support
non-constant indices (see PR116421).
As a pass I chose NRV for no particular reason except that it is
literally the last
On Wed, Sep 10, 2025 at 02:20:58AM -0700, Andrew Pinski wrote:
> On Tue, Aug 26, 2025 at 10:42 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > Bootstrapped and regtested on x86_64 and s390. Ok for mainline?
> >
> > -- >8 --
> >
> > In case an asm o
> + rtx extreg = gen_reg_rtx (DImode);
> + rtx clzreg = gen_reg_rtx (DImode);
> + emit_insn (gen_zero_extendsidi2 (extreg, operands[1]));
> + emit_insn (gen_clzdi2 (clzreg, extreg));
> + rtx truncreg = gen_lowpart (SImode, clzreg);
> + emit_insn (gen_addsi3 (operands[0], truncre
ruction offers that
> capability.
>
> Bootstrapped and regtested on s390x.
Committed as r16-3735-g7a49952100f.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (*vec_extract_plus_zero_extend):
> Fix define insn.
>
> gcc/testsuite/Change
; argument in that case is the default, which changed from 2 to -128.
> But spaceship-fp-1.c test also doesn't test what libstdc++ uses anymore,
> so the following patch uses -128 in all the spots.
>
> Ok for trunk?
Ok and thanks for looking into this!
Cheers,
Stefan
>
Bootstrapped and regtested on x86_64 and s390. Ok for mainline?
-- >8 --
In case an asm operand is an error node, constraints etc. are still
validated. Furthermore, all other operands are gimplified, although an
error is returned in the end anyway. For hard register constraints an
operand is r
From: Stefan Schulze Frielinghaus
In commit r16-2316-gc6676092318 mistakenly patterns were introduced
which actually should have been merged as alternatives to existing zero
extend patterns.
While on it, generalize the vec_extract patterns and also allow
registers for the index. A subsequent
On Wed, Aug 13, 2025 at 07:15:37PM +0200, Christophe Lyon wrote:
> Hi Stefan,
>
> On Tue, 12 Aug 2025 at 13:38, Stefan Schulze Frielinghaus
> wrote:
> >
> > From: Stefan Schulze Frielinghaus
> >
> > This test is about register pairs. On arm a long long
From: Stefan Schulze Frielinghaus
This test is about register pairs. On arm a long long is accepted in
thumb mode in any register 0-6 whereas in arm mode this is restricted to
even register pairs. Thus, in order to trigger the error even if gcc is
configured with --with-mode=thumb, add option
Ping patch 1/2.
I think we can skip patch 2/2 since this was meanwhile fixed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692272.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692268.html
On Thu, Jul 24, 2025 at 12:03:43PM +0200, Stefan Schulze Frielinghaus wrote:
>
From: Stefan Schulze Frielinghaus
In case an asm operand is an error node, constraints etc. are still
validated. Furthermore, all other operands are gimplified, although an
error is returned in the end anyway. For hard register constraints an
operand is required in order to determine the mode
On Wed, Aug 06, 2025 at 05:57:14PM +0200, Jakub Jelinek wrote:
> On Wed, Aug 06, 2025 at 05:40:09PM +0200, Stefan Schulze Frielinghaus wrote:
> > On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> > > On Tue, Aug 05, 2025 at 04:25:43PM +0200, J
On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> > On Tue, Aug 05, 2025 at 04:23:14PM +0200, Stefan Schulze Frielinghaus wrote:
> > > From: Stefan Schulze Frielinghaus
> > >
From: Stefan Schulze Frielinghaus
---
htdocs/gcc-16/changes.html | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-16/changes.html b/htdocs/gcc-16/changes.html
index a75d3b5a..3badf578 100644
--- a/htdocs/gcc-16/changes.html
+++ b/htdocs/gcc-16/changes.html
On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> On Tue, Aug 05, 2025 at 04:23:14PM +0200, Stefan Schulze Frielinghaus wrote:
> > From: Stefan Schulze Frielinghaus
> >
> > From: Stefan Schulze Frielinghaus
> >
> > gcc/ChangeLog:
> >
>
From: Stefan Schulze Frielinghaus
From: Stefan Schulze Frielinghaus
gcc/ChangeLog:
* explow.cc (promote_function_mode): Allow targets to promote
_BitInt arguments.
---
Bootstrapped and regtested on s390. Ok for mainline?
gcc/explow.cc | 2 +-
1 file changed, 1 insertion
From: Stefan Schulze Frielinghaus
From: Stefan Schulze Frielinghaus
gcc/ChangeLog:
* config/s390/s390.cc (print_operand): Allow arbitrary wide_int
constants for _BitInt.
(s390_bitint_type_info): Implement target hook
TARGET_C_BITINT_TYPE_INFO.
libgcc/ChangeLog
From: Stefan Schulze Frielinghaus
From: Stefan Schulze Frielinghaus
Enable soft-fp for -m64 only.
libgcc/ChangeLog:
* config.host: Include makefiles t-softfp for -m64.
* config/s390/sfp-exceptions.c: New file.
* config/s390/sfp-machine.h: New file.
* config
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)
> >
static inline size_t
insn_constraint_len (char fc, const char *str)
{
...
if (str[0] == '{')
return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
return 1;
}
For some reason on all targets I tested, string.h is included. I will
have a look and see whether string.h
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
anymore and sometimes even harmful. Remove the overwrite to
> align s390 with other backends.
Ok for mainline.
Thanks,
Stefan
>
> Signed-off-by: Juergen Christ
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_option_override_internal): Remove override.
>
> +sum += p[i];
> + return sum;
> +}
> +
> +unsigned int
> +__attribute__((noipa, optimize("Ofast")))
> +reduce_add_uint (unsigned int* p)
> +{
> + unsigned int sum = 0;
> + for (int i = 0; i != 16; i++)
> +sum += p[i];
> + return sum;
> +}
> +
>
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.
_VXE3_DT [(match_operand:VIT_HW_VXE3_DT 1
> "register_operand" "v")
> - (match_operand:VIT_HW_VXE3_DT 2
> "register_operand" "v")]
> - UNSPEC_VEC_SMULT_HI))]
> + (smul_highpart:VIT_HW_VXE3_DT (match_operand:VIT_HW_VXE3_DT 1
> "register_operand" "v")
> +
"register_operand" "=v")
> + (unspec:VFT_BFP [(match_operand:VFT_BFP 1 "register_operand" "v")
> + (match_operand:VFT_BFP 2 "register_operand" "v")
> + (match_operand:QI 3 "
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
manually.
>
> The following patch should fix that.
>
> Ok for trunk/15.2?
Ok.
Thanks,
Stefan
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:
> >
> &
uot;register_operand" "v")]
> +UNSPEC_VEC_UMULT_HI))]
> + "TARGET_VX")
In commit r12-4231-g555fa3545efe23 RTX smul_highpart and umul_highpart
were introduced which we could use instead of the unspec, now. So one
solution would be to move vec_sm
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:
>
> * c
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
f from:
(mem:QI (const:DI (unspec:DI [(symbol_ref:DI ("foo"))]
UNSPEC_PLT/GOTENT))) */
y = XEXP (x, 0);
if (GET_CODE (y) == UNSPEC
&& (XINT (y, 1) == UNSPEC_GOTENT
|| XINT (y, 1) == UNSPEC_PLT31))
y = XVECEXP (y, 0, 0);
else
return orig_x;
}
is questionable to me. Shouldn't we in this case if also
GET_MODE (orig_x) != Pmode holds, return the SYMBOL_REF wrapped in a MEM
with mode of orig_x instead?
Cheers,
Stefan
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
ecific lanes.
>
> Bootstrapped and regtested on s390x.
Ok for mainline.
Thanks,
Stefan
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (VF): New mode iterator.
> (VEC_SET_NONFLOAT): New mode iterator.
> (VEC_SET_SINGLEFLOAT): New mode iterator.
>
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
+** br %r14
> +*/
> +float
> +sumfirstfloat (V4SF x, V4SF y)
> +{
> + return (x + y)[0];
> +}
> +
> +/*
> +** extractfirst2:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +float
> +extractfirst2 (V2SF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsecond2:
> +** vrepf %v0,%v24,1
> +** br %r14
> +*/
> +float
> +extractsecond2 (V2SF x)
> +{
> + return x[1];
> +}
> +
> +/*
> +** extractnth2:
> +** vlgvf (%r.),%v24,0\(%r2\)
> +** vlvgf %v0,\1,0
> +** br %r14
> +*/
> +float
> +extractnth2 (V2SF x, int n)
> +{
> + return x[n];
> +}
> +
> +/*
> +** extractsinglef:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +float
> +extractsinglef (V1SF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsingled:
> +** vlr %v0,%v24
> +** br %r14
> +*/
> +double
> +extractsingled (V1DF x)
> +{
> + return x[0];
> +}
> +
> +/*
> +** extractsingleld:
> +** vlr (%v.),%v24
> +** vst \1,0\(%r2\),3
> +** br %r14
> +*/
> +long double
> +extractsingleld (V1TF x)
> +{
> + return x[0];
> +}
> diff --git a/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> b/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> new file mode 100644
> index ..2eddb58290f6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/vector/vec-set-1.c
> @@ -0,0 +1,67 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=z14 -mzarch" } */
> +/* { dg-final { check-function-bodies "**" "" } } */
> +
> +typedef double V2DF __attribute__((vector_size(16)));
> +typedef double V1DF __attribute__((vector_size(8)));
> +
> +/*
> +** setdf0:
> +** vpdi%v24,%v0,%v24,1
> +** br %r14
> +*/
> +V2DF
> +setdf0 (V2DF x, double y)
> +{
> + x[0] = y;
> + return x;
> +}
> +
> +/*
> +** setdf1:
> +** vmrhg %v24,%v24,%v0
> +** br %r14
> +*/
> +V2DF
> +setdf1 (V2DF x, double y)
> +{
> + x[1] = y;
> + return x;
> +}
> +
> +/*
> +** setdfn:
> +** lgdr(%r.),%f0
> +** vlvgg %v24,\1,0\(%r2\)
> +** br %r14
> +*/
> +V2DF
> +setdfn (V2DF x, double y, int n)
> +{
> + x[n] = y;
> + return x;
> +}
> +
> +/*
> +** set1df:
> +** vlr %v24,%v0
> +** br %r14
> +*/
> +V1DF
> +set1df (V1DF x, double y)
> +{
> + x[0] = y;
> + return x;
> +}
> +
> +/*
> +** set1dfn:
> +** vlr %v24,%v0
> +** br %r14
> +*/
> +V1DF
> +set1dfn (V1DF x, double y, int n)
> +{
> + x[n] = y;
> + return x;
> +}
I very much like those tests. Could you add for the sake of completeness
also some SF tests for vec-set-1.c?
> --
> 2.43.5
>
Could you run a bootstrap and regtest?
Thanks,
Stefan
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 @
x-linux, ok for trunk and 15.2 (with
> CALL_EXPR_MUST_TAIL_CALL (call_expr) && added in that case)?
Ok. Thanks for taking care of this!
Cheers,
Stefan
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
ARALLEL is used
exclusively in case a register pair is required. Though, I'm not sure
whether this is correct or not. There doesn't seem to exist a test for
this. I will look into this.
Note, on s390 a parameter is either passed in a register (pair) or via
memory, but not partly in a register and memory.
Cheers,
Stefan
non-extended values. Maybe a
check like
REGNO (parm) == REGNO (parm_rtx)
&& REG_NREGS (parm) == REG_NREGS (parm_rtx)
is sufficient?
Cheers,
Stefan
>
> Bootstrapped/regtested on s390x-linux, ok for trunk?
>
> I wonder if we shouldn't do this for 15.1 as well with additional
>
hat case is X for the first variant, so still just fine. But we won't
> > split that because the splitters only expect scratch.
> >
> > The following patch fixes it by using match_scratch instead of scratch,
> > so that it accepts either.
> >
> > Bo
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
s to prepare for a future removal of -m31; though in smaller steps. Thus,
instead of introducing some potential hick ups along the route, I will revert
this patch and will revisit this topic when time for -m31 in its entirety has
come---independent of -mesa/-mzarch.
Cheers,
Stefan
[1] https://gcc.gnu
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
init -Wenum-conversion -Wextra -Wunused
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> -Wno-packed-not-aligned -Wno-format-overflow -Wno-format-truncation
> -Wno-stringop-truncation -Wno-override-init -Wno-missing-field-initializers
> -Wno-type-limits -Wno-shift-negative
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
ior of
> double-word smin/smax/umin/umax with various cases of the halves of both
> operands (one that is sometimes EQ, sometimes GT, sometimes LT, sometimes
> GTU, sometimes LTU).
>
> Stefan has successfully bootstrapped/regtested this on s390x-linux (thanks
> for that; I'm
ts or there are not enough registers" } */
(I have tested those only on x86_64 so far but I expect them to work on
32-bit, too, module int128)
I will include those, and of course, similar ones for constraints
b,c,d,S,D in a future patch revision. If there is any other target with
non-ordinary register classes/constraints/whatnot just let me know and I
will have a look.
> I'm sure someone will try to implement ABI semantics for asms with calls at
> some point on top of this infrastructure. It seems to be a persistent thing
> developers want to do with asms. It always ends in a bit of fireworks
> either running out of registers in the asm itself or generating crappy code
> because of all the hard register usages. Not something you need to fix,
> more a rant about what's likely to happen in the future ;-)
Heh, yes maybe ... I hope not ;-) Ultimately I hope to get rid of those
hard to find bugs which are introduced by implicit function calls by
demoting register asm into hard register constraints.
Cheers,
Stefan
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
1 - 100 of 449 matches
Mail list logo
