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
On Fri, Jan 17, 2025 at 10:47:09AM +0100, Jakub Jelinek wrote:
> Hi!
>
> r15-2002 s390: Fully exploit vgm, vgbm, vrepi change added
> some code to print_operand and added gcc_checking_asserts in there.
> But print_operand ideally should have no assertions in it, as most
> of the assumptions can be
On Wed, Jan 15, 2025 at 10:29:03PM -0700, Jeff Law wrote:
>
>
> On 11/29/24 2:15 AM, Stefan Schulze Frielinghaus wrote:
> > Ping.
> >
> > On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
> > > This is a follow-up to
> > &
Merge new optabs with the existing implementations for signbit and
isinf.
gcc/ChangeLog:
* config/s390/s390.h (S390_TDC_POSITIVE_ZERO): Remove.
(S390_TDC_NEGATIVE_ZERO): Remove.
(S390_TDC_POSITIVE_NORMALIZED_BFP_NUMBER): Remove.
(S390_TDC_NEGATIVE_NORMALIZED_BFP_NU
On Thu, Jan 09, 2025 at 07:21:53PM +0100, Jakub Jelinek wrote:
> On Thu, Jan 09, 2025 at 01:29:27PM +0100, Stefan Schulze Frielinghaus wrote:
> > Optimization s390_constant_via_vgbm_p() should only apply to constant
> > vectors which can be expressed by the hardware, i.e., which hav
Optimization s390_constant_via_vgbm_p() should only apply to constant
vectors which can be expressed by the hardware, i.e., which have a size
of at most 16-bytes, similar as it is done for s390_constant_via_vgm_p()
and s390_constant_via_vrepi_p().
gcc/ChangeLog:
PR target/118362
*
. Of course, if anyone else
wants to join in I would be happy, too ;-)
Cheers,
Stefan
On Fri, Nov 29, 2024 at 10:15:45AM +0100, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
> > This is a follow-
For some targets uptr is mapped to unsigned int and size_t to unsigned
long and sizeof(int)==sizeof(long) holds. Still, these are distinct
types and type checking may fail. Therefore, replace uptr by
usize/SIZE_T wherever a size_t is expected.
Part of #116957
Cherry picked from LLVM commit 9a15
On Mon, Jan 06, 2025 at 10:49:31AM +0100, Jakub Jelinek wrote:
> On Mon, Jan 06, 2025 at 09:55:16AM +0100, Stefan Schulze Frielinghaus wrote:
> > For some targets uptr is mapped to unsigned int and size_t to unsigned
> > long and sizeof(int)==sizeof(long) holds. Still, the
Since the sanitizer merge in commit r15-5164-gfa321004f3f628 of GCC
which entails LLVM commit 61a6439f35b6de28ff4aff4450d6fca970292fd5, GCCs
bootstrap is broken on s390 -m31. This is due to commit
ec68dc1ca4d967b599f1202855917d5ec9cae52f which introduces stricter type
checking which is why GCC boot
For some targets uptr is mapped to unsigned int and size_t to unsigned
long and sizeof(int)==sizeof(long) holds. Still, these are distinct
types and type checking may fail. Therefore, replace uptr by
usize/SIZE_T wherever a size_t is expected.
Part of #116957
Cherry picked from LLVM commit 9a15
This is a follow-up to 6dec33834d1fd89f16e271dde9607c1de9554144 and
#116957 and #119114.
Cherry picked from LLVM commit 65a2eb0b1589590ae78cc1e5f05cd004b3b3bec5.
PR sanitizer/117725
libsanitizer/ChangeLog:
* sanitizer_common/sanitizer_common_interceptors.inc: Cherry
picked from L
From: Vitaly Buka
Fix type in a few related Min() calls.
Follow up to #116957.
Co-authored-by: Stefan Schulze Frielinghaus
Cherry picked from LLVM commit 6dec33834d1fd89f16e271dde9607c1de9554144
(removed memprof part).
PR sanitizer/117725
libsanitizer/ChangeLog:
* asan
These four cherry picks resolve PR117725, i.e., bootstrap is restored on
s390 -m31. Ok for mainline?
--
2.47.0
t; Am 10.09.24 um 16:20 schrieb Stefan Schulze Frielinghaus:
> > This series introduces hard register constraints. The first patch
> > enables hard register constraints for asm statements and for
> > machine descriptions. The subsequent patch adds some basic error
> > han
Ping.
On Fri, Oct 25, 2024 at 11:57:16AM +0200, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to
> https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663238.html
>
> The primary changes are about error handling and documentation updates.
> Now, we error out
Bootstrap and regtest are still running. If those are successful and
there are no further comments I will push this one in the coming days.
-- >8 --
gcc/ChangeLog:
* config/s390/s390-protos.h (s390_emit_compare): Add mode
parameter for the resulting RTX.
* config/s390/s3
On Mon, Nov 18, 2024 at 09:32:29AM +0100, Andreas Krebbel wrote:
> Hi Stefan,
>
>
> On 11/12/24 10:35, Stefan Schulze Frielinghaus wrote:
> > > > + rtx cond = gen_rtx_LTU (mode, gen_rtx_REG (CCL1mode,
> > > > CC_REGNUM), const0_rtx);
>
On Mon, Nov 11, 2024 at 11:29:16AM +0100, Andreas Krebbel wrote:
> Hi Stefan,
>
> thanks for the patch and sorry for the slow review.
No worries. Thanks for the detailed review. Much appreciated!
>
>
> On 9/18/24 19:25, Stefan Schulze Frielinghaus wrote:
> > Boots
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.
Due to optimizations it is not unexpected if two or more inputs requi
r" (x), "=r" (x));
is accepted.
Thus, in total the changes make hard register constraints more strict in
order to prevent subtle bugs.
Stefan Schulze Frielinghaus (4):
Hard register constraints
Error handling for hard register constraints
genoutput: Verify har
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
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/ext-floating19.C: Fix typo for bfloat16 guard.
---
Ok for mainline?
gcc/testsuite/g++.dg/cpp23/ext-floating19.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/cpp23/ext-floating19.C
b/gcc/testsuite/g++.dg
port Stefan Schulze Frielinghaus
sh port Alexandre Oliva
sh port Oleg Endo
sparc port David S. Miller
--
2.45.2
I have been missing the two test cases and removed them since they
depend on -mno-lra.
-- 8< --
Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.
PR target/113953
gcc/ChangeLog:
* config/s390/s390.cc (s390_lra_p): Rem
Since the old reload pass is about to be removed and we defaulted to LRA
for over a decade, remove option -m{,no-}lra.
PR target/113953
gcc/ChangeLog:
* config/s390/s390.cc (s390_lra_p): Remove.
(TARGET_LRA_P): Remove.
* config/s390/s390.opt (mlra): Remove.
* conf
Bootstrapped and regtested on s390. Both expander are constrained to
z196 because of the conditional moves. I guess this is reasonable
nowadays.
Would be great if you could have a second look that setting the
carry/borrow bit (bit 18 of the PSW) is indeed correct. Brain twisted
me at first ;-)
On Wed, Sep 18, 2024 at 03:53:37PM +0200, Michael Matz wrote:
> Hello,
>
> On Thu, 12 Sep 2024, Stefan Schulze Frielinghaus wrote:
>
> > > > #define call_on_stack(stack, f
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
This implements some basic error handling for hard register constraints
including potential conflics 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 ex
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
nyway), then
just let me know.
Stefan Schulze Frielinghaus (4):
Hard register constraints
Error handling for hard register constraints
genoutput: Verify hard register constraints
Rewrite register asm into hard register constraints
gcc/cfgexpand.cc | 42 ---
Implement hard register constraints of the form {regname} where regname
must be any valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions.
Due to optimizations it is not unexpected if two or more inputs req
Bootstrapped and regtested on s390. Approved offlist and as also
discussed offlist I went for removing format specifier %V. This fixes
FAIL: g++.dg/cpp23/ext-floating14.C -std=gnu++23 execution test
FAIL: g++.dg/cpp23/ext-floating14.C -std=gnu++26 execution test
FAIL: c-c++-common/ubsan/float-
Ensure for AQ and AR constraints that the resulting displacement after
adding any positive offset less than the size of the object being
referenced is still valid.
Bootstrapped and regtested on s390. As approved by
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662865.html
I will push s
On Thu, Sep 12, 2024 at 04:03:33PM +0200, Georg-Johann Lay wrote:
>
>
> Am 10.09.24 um 16:20 schrieb Stefan Schulze Frielinghaus:
> > This series introduces hard register constraints. The first patch
> > enables hard register constraints for asm statements and for
> >
On Wed, Sep 11, 2024 at 08:57:23PM +0200, Ilya Leoshkevich wrote:
> On Wed, 2024-09-11 at 16:44 +0200, Stefan Schulze Frielinghaus wrote:
> > On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote:
> > > On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frieli
On Wed, Sep 11, 2024 at 01:59:48PM +0200, Ilya Leoshkevich wrote:
> On Wed, 2024-09-11 at 13:34 +0200, Stefan Schulze Frielinghaus wrote:
> > On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote:
> > > On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frieli
On Wed, Sep 11, 2024 at 01:22:30PM +0200, Ilya Leoshkevich wrote:
> On Wed, 2024-09-11 at 12:35 +0200, Stefan Schulze Frielinghaus wrote:
> > On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote:
> > > On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frieli
On Wed, Sep 11, 2024 at 11:47:54AM +0200, Ilya Leoshkevich wrote:
> On Fri, 2024-08-16 at 09:41 +0200, Stefan Schulze Frielinghaus wrote:
> > Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
> > survive register allocation. This in turn leads to wrong regist
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
Implement hard register constraints of the form {regname} where regname
must be any valid register name for the target. Such constraints may be
used in asm statements as a replacement for register asm and in machine
descriptions.
Due to optimizations it is not unexpected if two or more inputs req
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
This implements some basic error handling for hard register constraints
including potential conflics 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 ex
+' for the output constraint since the input is explicitly
mentioned, or remove the input entirely and just use the inoutput
[tos] "+r" (tos)
If you consider this valid asm I would have to adjust the error
handling. Either way, this is just about error handling and doesn&#x
Ping
On Fri, Aug 16, 2024 at 09:41:55AM +0200, Stefan Schulze Frielinghaus wrote:
> Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
> survive register allocation. This in turn leads to wrong register
> renaming. Keeping the current approach would mean we need two
Ping
On Fri, Aug 16, 2024 at 09:14:02AM +0200, Stefan Schulze Frielinghaus wrote:
> In s390_expand_insv(), if generating code for ICM et al. src is a MEM
> and gen_lowpart might force src into a register such that we end up with
> patterns which do not match anymore. Use adjust_address(
Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1
survive register allocation. This in turn leads to wrong register
renaming. Keeping the current approach would mean we need two insns for
*tf_to_fprx2_0 and *tf_to_fprx2_1, respectively. Something along the
lines
(define_insn
In s390_expand_insv(), if generating code for ICM et al. src is a MEM
and gen_lowpart might force src into a register such that we end up with
patterns which do not match anymore. Use adjust_address() instead in
order to preserve a MEM.
Furthermore, it is not straight forward to enforce a subreg.
The following intrinsics are not implemented. Thus, remove them.
Ok for mainline?
gcc/ChangeLog:
* config/s390/vecintrin.h (vec_vstbrh): Remove.
(vec_vstbrf): Remove.
(vec_vstbrg): Remove.
(vec_vstbrq): Remove.
(vec_vstbrf_flt): Remove.
(vec_vstbr
Starting with r14-9449-g9f2b16ce1efef0 builtins were streamlined with
those in LLVM. In particular s390_vgfm{,a}g have been changed from
UV16QI to UINT128 in order to match those in LLVM. However, these
low-level builtins are directly used by the high-level builtins
vec_gfmsum{,_accum}_128 which
On Mon, Aug 05, 2024 at 02:19:50PM +0200, Georg-Johann Lay wrote:
> Am 05.08.24 um 12:28 schrieb Stefan Schulze Frielinghaus:
> > This is a follow-up of
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html
> >
> > What has changed?
> >
&g
This is a follow-up of
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654013.html
What has changed?
- Rebased and fixed an issue in constrain_operands which manifested
after late-combine.
- Introduced new test cases for Arm, Intel, POWER, RISCV, S/390 for 32-
and 64-bit where appropriate (i
On Tue, Jul 23, 2024 at 11:40:00AM -0600, Jeff Law wrote:
>
>
> On 7/23/24 9:45 AM, Stefan Schulze Frielinghaus wrote:
>
> >
> > > They come from:
> > > ```
> > > (define_insn "*tf_to_fprx2_0"
> > >[(set
On Mon, Jul 22, 2024 at 08:16:16PM -0700, Andrew Pinski wrote:
> On Sun, Jul 21, 2024 at 11:47 PM Stefan Schulze Frielinghaus
> > diff --git a/gcc/regrename.cc b/gcc/regrename.cc
> > index 054e601740b..6ae5a2309d0 100644
> > --- a/gcc/regrename.cc
> > +++ b/gcc/regrename
It is not trivial to decide when a write of a register pair terminates
or starts a new chain. For example, prior regrename we have
(insn 91 38 36 5 (set (reg:FPRX2 16 %f0 [orig:76 x ] [76])
(const_double:FPRX2 0.0 [0x0.0p+0]))
"float-cast-overflow-7-reduced.c":5:55 discrim 2 1507 {*movfp
I'm pinging this early since I would like to make sure that it gets into
14.2 RC which is about to be done on Tuesday 23rd July.
On Tue, Jul 16, 2024 at 04:50:29PM +0200, Stefan Schulze Frielinghaus wrote:
> Code attribute bhfgq is missing a mapping for TF. This results in
> unresolve
On Thu, Jul 18, 2024 at 11:58:10PM -0700, Andrew Pinski wrote:
> On Thu, Jul 18, 2024 at 10:31 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > Previously we optimized expressions of the form a < 0 ? -1 : 0 to
> > (signed)a >> 31 during vcond expanding. Since r15
Previously we optimized expressions of the form a < 0 ? -1 : 0 to
(signed)a >> 31 during vcond expanding. Since r15-1741-g2ccdd0f22312a1
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
1 - 100 of 321 matches
Mail list logo
