"multiple outputs to hard register: %r2"
This is due to the error handling in gimplify_asm_expr (). Speaking of errors,
I also error out earlier as before which means that e.g. in pr87600-2.c only
the first error is reported and processing is stopped afterwards which means
t
t;
> > gcc/ChangeLog:
> >
> > * ifcvt.cc (noce_process_if_block): Subtract condition pattern
> > cost if applicable.
> > (noce_find_if_block): Use insn_cost and pattern_cost for
> > original cost.
> OK. Obviously we'll need to be on the lookout for regressions. My bet is
> on s390 since you already tested the x86, aarch64 & p10 targets :-)
I just gave it a try on s390 where bootstrap and regtest were successful.
Cheers,
Stefan
>
>
> jeff
>
Since the patch works fine so far for mainline, ok to backport to GCC 14?
On Fri, May 17, 2024 at 08:59:05AM +0200, Stefan Schulze Frielinghaus wrote:
> I've adapted the patch as follows and will push.
>
> Thanks,
> Stefan
>
> --
>
> Consider a NOCE conversion
Starting with r14-5628-g53ba8d669550d3 interprocedural VRP became strong
enough in order to render these tests useless. Fixed by disabling IPA.
gcc/testsuite/ChangeLog:
* gcc.target/s390/nobp-table-jump-inline-z10.c: Do not perform
IPA.
* gcc.target/s390/nobp-table-jump-i
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
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
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.
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
With the change of r15-787-g57e04879389f9c I forgot to also update this
test.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc.
---
Ok for mainline? Ok for GCC 14 if the corresponding backport is also
approved?
gcc/testsuite/gcc.target/s390/ifcvt-one-insn-boo
Ping.
On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
> This implements hard register constraints for inline asm. A hard register
> constraint is of the form {regname} where regname is any valid register. This
> basically renders register asm superflu
For the moment I deliberately left out one-element QHS vectors since it
is unclear whether these are pathological cases or whether they are
really used. If we ever get an extend for V1DI -> V1TI we should
reconsider this.
As a side-effect this fixes PR115261.
gcc/ChangeLog:
target/PR115
This implements a V2SF -> V2DF extend.
gcc/ChangeLog:
* config/s390/vector.md (*vmrhf): New.
(extendv2sfv2df2): New.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/vec-extend-3.c: New test.
---
Bootstrap and regtested on s390. Ok for mainline?
gcc/config/s390/vect
On Tue, Jun 11, 2024 at 10:42:26AM +0200, Andreas Krebbel wrote:
> On 6/11/24 10:26, Stefan Schulze Frielinghaus wrote:
> > This implements a V2SF -> V2DF extend.
> >
> > gcc/ChangeLog:
> >
> > * config/s390/vector.md (*vmrhf): New.
> > (ext
Ping.
On Mon, Jun 03, 2024 at 03:43:39PM +0200, Stefan Schulze Frielinghaus wrote:
> Starting with r14-5628-g53ba8d669550d3 interprocedural VRP became strong
> enough in order to render these tests useless. Fixed by disabling IPA.
>
> gcc/testsuite/ChangeLog:
>
> * gc
Ping.
On Sun, Jun 02, 2024 at 02:07:24PM +0200, Stefan Schulze Frielinghaus wrote:
> Since the patch works fine so far for mainline, ok to backport to GCC 14?
>
> On Fri, May 17, 2024 at 08:59:05AM +0200, Stefan Schulze Frielinghaus wrote:
> > I've adapted the patch as f
Ping.
On Wed, Jun 05, 2024 at 08:00:15AM +0200, Stefan Schulze Frielinghaus wrote:
> With the change of r15-787-g57e04879389f9c I forgot to also update this
> test.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/ifcvt-one-insn-bool.c: Fix loc.
> ---
> Ok for
s)? And
> whether they choose to implement all condition codes in vec_cmp
> and adjust with inversion / operand swapping for not supported cases?
On s390 we support all comparison operations with inverse / operand
swapping via s390_expand_vec_compare. However, we still have some
failures
On Thu, Jun 20, 2024 at 09:06:11AM +0200, Juergen Christ wrote:
> Some casts were missing leading to missed of bad vectorizations where
> casting was done scalar followed by a vector creation from the
> individual elements.
>
> gcc/ChangeLog:
>
> * config/s390/vector.md (VEC_HALF_NARROWED):
Ping.
On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
> Ping.
>
> On Fri, May 24, 2024 at 11:13:12AM +0200, Stefan Schulze Frielinghaus wrote:
> > This implements hard register constraints for inline asm. A hard register
> > constraint is of the
On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
>
>
> > On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > Ping.
> >
> > On Mon, Jun 10, 2024 at 07:19:19AM +0200, Stefan Schulze Frielinghaus wrote:
> >>
An explicit check for address registers was not required so far since
during register allocation the processing of address constraints was
sufficient. However, address constraints themself do not check for
REGNO_OK_FOR_{BASE,INDEX}_P. Thus, with the newly introduced
late-combine pass in r15-1579-
On Tue, Jun 25, 2024 at 01:02:39PM -0400, Paul Koning wrote:
>
>
> > On Jun 25, 2024, at 12:04 PM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > On Tue, Jun 25, 2024 at 10:03:34AM -0400, Paul Koning wrote:
> >>
> >>>>> ...
> &g
On Wed, Jun 26, 2024 at 02:15:18PM +0200, Stefan Schulze Frielinghaus wrote:
> An explicit check for address registers was not required so far since
> during register allocation the processing of address constraints was
> sufficient. However, address constraints themself do not
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
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
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
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 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
As mentioned in PR114678 those failures will be fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
For GCC 14 just xfail them which should be reverted once the patch is
applied.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/range-sincos.c: Xfail for s390.
* gcc
Starting with r14-9316-g7890836de20912 patterns for vpopct{b,h} are also
detected. Thus, remove xfails.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vxe/popcount-1.c: Remove xfail.
---
Ok for mainline?
gcc/testsuite/gcc.target/s390/vxe/popcount-1.c | 4 ++--
1 file changed, 2 insertions
The tests fail on s390 since can_vec_perm_const_p fails and therefore
the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
Strictly speaking, the tests only fail in case the target supports
vectors, i.e., for targets prior z13 or in case of -mesa the emulated
vector operations are op
Hi Andreas,
Ok then I will proceed with the patch as is. Opened PR114802.
Cheers,
Stefan
--
The tests fail on s390 since can_vec_perm_const_p fails and therefore
the bit insert/ref survive which r14-3381-g27de9aa152141e aims for.
Strictly speaking, the tests only fail in case the target
Bitcount operations popcount, clz, and ctz are emulated for narrow modes
in case an operation is only supported for wider modes. Beside that ctz
may be emulated via clz in expand_ctz. Reflect this in
expression_expensive_p.
I considered the emulation of ctz via clz as not expensive since this
ba
Starting with r12-2731-g96146e61cd7aee we do not generate code like
_5 = (unsigned int) c_2(D);
i_6 = _5 << 8;
_7 = _5 << 20;
i_8 = i_6 | _7;
anymore but instead
_5 = (unsigned int) c_2(D);
_3 = _5 * 1048832;
which leads finally to slightly different assembly code where we
previously ended up f
Starting with r14-2047-gd0e891406b16dc we see through subregs which
means for f10 in risbg-ll-2.c we do not end up with rosbg_si_noshift but
rather rosbg_di_noshift which materializes in slightly different start
index. This saves us an extend.
gcc/testsuite/ChangeLog:
* gcc.target/s390/r
Ping. Ok for mainline?
On Thu, Apr 25, 2024 at 09:26:45AM +0200, Stefan Schulze Frielinghaus wrote:
> Bitcount operations popcount, clz, and ctz are emulated for narrow modes
> in case an operation is only supported for wider modes. Beside that ctz
> may be emulated via clz in e
On s390 the following tests fail
FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
optimized " = .CLZ (vect" 1
FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times
optimized " = .POPCOUNT (vect" 1
FAIL: gcc.dg/vect/pr109011-1.c scan-tree
Consider a NOCE conversion as profitable if there is at least one
conditional move.
gcc/ChangeLog:
* config/s390/s390.cc (TARGET_NOCE_CONVERSION_PROFITABLE_P):
Define.
(s390_noce_conversion_profitable_p): Implement.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ccor
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(
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
+' 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
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
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
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
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
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 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 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 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
> >
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
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-
On Tue, Jan 28, 2020 at 06:18:41PM +0100, Stefan Schulze Frielinghaus wrote:
> On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote:
> > On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> > > some function calls trigger the stack-protector-st
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
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
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
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
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
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 ;-)
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
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 ---
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
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
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
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
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 Sat, Dec 07, 2024 at 08:49:20AM +0100, Georg-Johann Lay wrote:
> Is there a PR for this feature? (Just to make sure that I don't
> miss progress on this I could CC to the PR).
No. However, I can CC you in case of further patch revisions.
Cheers,
Stefan
>
> Johann
>
&g
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
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
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
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
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
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
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
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
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
. 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-
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
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
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
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
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.
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
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
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
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 (
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):
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
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
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
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
101 - 200 of 414 matches
Mail list logo
