https://gcc.gnu.org/g:3eb3fbc89c638a72611efdc54110b8113f79ee8d
commit r14-10713-g3eb3fbc89c638a72611efdc54110b8113f79ee8d
Author: Stefan Schulze Frielinghaus
Date: Thu Sep 26 19:38:02 2024 +0200
s390: Fix TF to FPRX2 conversion [PR115860]
Currently subregs originating from
https://gcc.gnu.org/g:1670d3259dec8abf445ed4f282dcbf3a1e0d3032
commit r14-10712-g1670d3259dec8abf445ed4f282dcbf3a1e0d3032
Author: Stefan Schulze Frielinghaus
Date: Thu Sep 26 19:38:02 2024 +0200
s390: Fix AQ and AR constraints
Ensure for AQ and AR constraints that the resulting
https://gcc.gnu.org/g:4fe0b88159a9548f90db4e846f2033d51e1506c7
commit r12-10717-g4fe0b88159a9548f90db4e846f2033d51e1506c7
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 20 14:08:32 2024 +0200
s390: Fix strict_low_part generation
In s390_expand_insv(), if generating code for
https://gcc.gnu.org/g:edda7ba3b569652eb782a7c47a4ad32e3c0e29dd
commit r13-9045-gedda7ba3b569652eb782a7c47a4ad32e3c0e29dd
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 20 14:07:36 2024 +0200
s390: Fix strict_low_part generation
In s390_expand_insv(), if generating code for ICM
https://gcc.gnu.org/g:bff6e5667d6a8bf8060e550bdcb40e094d00af41
commit r14-10692-gbff6e5667d6a8bf8060e550bdcb40e094d00af41
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 20 14:06:42 2024 +0200
s390: Fix strict_low_part generation
In s390_expand_insv(), if generating code for
https://gcc.gnu.org/g:09a52cf036ba8f2fa7b60b18ba58ca17ffa1b146
commit r15-3733-g09a52cf036ba8f2fa7b60b18ba58ca17ffa1b146
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 20 13:53:08 2024 +0200
s390: Remove -m{,no-}lra option
Since the old reload pass is about to be removed and
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
https://gcc.gnu.org/g:46c2538435dfc50dd5c67c4e03ce387d1f6ebe9b
commit r15-3626-g46c2538435dfc50dd5c67c4e03ce387d1f6ebe9b
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 13 15:09:55 2024 +0200
s390: Fix TF to FPRX2 conversion [PR115860]
Currently subregs originating from
https://gcc.gnu.org/g:1a71ff3b89aadc7fa0af0bca269d74bb23c1a957
commit r15-3625-g1a71ff3b89aadc7fa0af0bca269d74bb23c1a957
Author: Stefan Schulze Frielinghaus
Date: Fri Sep 13 15:05:33 2024 +0200
s390: Fix AQ and AR constraints
Ensure for AQ and AR constraints that the resulting
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 Fri, Aug 09, 2024 at 09:49:03AM +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, Aug 08, 2024 at 01:56:48PM -0600, Jeff Law wrote:
> > > I haven't tested it extensively but it triggers at least for the current
> > > case.
> > > I would have loved to also
https://gcc.gnu.org/g:9ebc9fbdddfe1ec85355b068354315a4da8e1ca0
commit r15-3602-g9ebc9fbdddfe1ec85355b068354315a4da8e1ca0
Author: Stefan Schulze Frielinghaus
Date: Thu Sep 12 13:29:43 2024 +0200
s390: Fix strict_low_part generation
In s390_expand_insv(), if generating code for ICM
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.
https://gcc.gnu.org/g:e903ada5e8881acec734eb3f89c3644bbd8da7e9
commit r14-10582-ge903ada5e8881acec734eb3f89c3644bbd8da7e9
Author: Stefan Schulze Frielinghaus
Date: Wed Aug 14 20:12:35 2024 +0200
s390: Fix high-level builtins vec_gfmsum{,_accum}_128
Starting with r14-9449
https://gcc.gnu.org/g:a247088adaf122116919235f4a40189506139495
commit r15-2919-ga247088adaf122116919235f4a40189506139495
Author: Stefan Schulze Frielinghaus
Date: Wed Aug 14 20:01:43 2024 +0200
s390: Remove vector intrinsics
The following intrinsics are not implemented. Thus
https://gcc.gnu.org/g:e8a7142a697c5d2673adea33ba23af82a89c9559
commit r15-2918-ge8a7142a697c5d2673adea33ba23af82a89c9559
Author: Stefan Schulze Frielinghaus
Date: Wed Aug 14 20:01:36 2024 +0200
s390: Fix high-level builtins vec_gfmsum{,_accum}_128
Starting with r14-9449
aving more testing would be great. I've attached a new patch.
Cheers,
Stefan
>From 0199088d2877c9c840ce984f61365816879818bc Mon Sep 17 00:00:00 2001
From: Stefan Schulze Frielinghaus
Date: Fri, 9 Aug 2024 09:45:57 +0200
Subject: [PATCH] rtl: Verify pseudo register references
Ensure that each pseudo register referenced in an
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 Thu, Aug 08, 2024 at 07:57:43AM -0600, Jeff Law wrote:
>
>
> On 8/8/24 6:26 AM, Stefan Schulze Frielinghaus wrote:
> > On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote:
> > >
> > >
> > > On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via
On Thu, Aug 08, 2024 at 06:03:13AM -0600, Jeff Law wrote:
>
>
> On 8/8/24 5:15 AM, Stefan Schulze Frielinghaus via Gcc wrote:
>
> >
> > However `(reg:DI 61 [ MEM[(const union T *)p_2(D)] ])` referencing the
> > same pseudo in a different mode is not substituted in
Hi all,
While trying to fix the failing test gcc.dg/torture/pr111821.c on s390 I'm
stumbling across another problem. After ira we have
(note 4 1 18 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 18 4 2 2 (set (reg:DI 66)
(reg:DI 2 %r2 [ p ])) "/gcc/testsuite/gcc.dg/torture/pr111821.c":5:1
1503 {
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
https://gcc.gnu.org/g:7ad764fe3c3ad0e1167b58cf3785629d788491f4
commit r12-10627-g7ad764fe3c3ad0e1167b58cf3785629d788491f4
Author: Stefan Schulze Frielinghaus
Date: Sat Jul 20 17:13:03 2024 +0200
s390: Fix unresolved iterators bhfgq and xdee
Code attribute bhfgq is missing a
https://gcc.gnu.org/g:130edabae09e18064e0bdcb12656e4f4f9a51ff3
commit r13-8927-g130edabae09e18064e0bdcb12656e4f4f9a51ff3
Author: Stefan Schulze Frielinghaus
Date: Sat Jul 20 16:05:41 2024 +0200
s390: Fix unresolved iterators bhfgq and xdee
Code attribute bhfgq is missing a
https://gcc.gnu.org/g:bb34b7eda1fbfcfe108d985fd0ae1421c2fa14c0
commit r14-10482-gbb34b7eda1fbfcfe108d985fd0ae1421c2fa14c0
Author: Stefan Schulze Frielinghaus
Date: Sat Jul 20 16:03:33 2024 +0200
s390: Fix unresolved iterators bhfgq and xdee
Code attribute bhfgq is missing a
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
Code attribute bhfgq is missing a mapping for TF. This results in
unresolved iterators in assembler templates for *bswaptf.
With the TF mapping added the base mnemonics vlbr and vstbr are not
"used" anymore but only the extended mnemonics (vlbr was
interpreted as vlbr; likewise for vstbr). There
https://gcc.gnu.org/g:9e00ae3e23eef8bff497981e00853ca092772201
commit r12-10620-g9e00ae3e23eef8bff497981e00853ca092772201
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 14:01:58 2024 +0200
s390: Fix output template for movv1qi
Although for instructions MVI and MVIY it does
https://gcc.gnu.org/g:06d825719fd4b71c8e3d34fd9756be7f847b
commit r12-10619-g06d825719fd4b71c8e3d34fd9756be7f847b
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 14:01:50 2024 +0200
s390: Align *cjump_64 and *icjump_64
During machine reorg we optimize backward jumps
https://gcc.gnu.org/g:1accf7036570cbb0fef9afa595634be03f8c14e8
commit r13-8918-g1accf7036570cbb0fef9afa595634be03f8c14e8
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 13:59:38 2024 +0200
s390: Fix output template for movv1qi
Although for instructions MVI and MVIY it does
https://gcc.gnu.org/g:544b65cddf296a63dfb91c6ffa4f474ae9d70052
commit r13-8917-g544b65cddf296a63dfb91c6ffa4f474ae9d70052
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 13:59:06 2024 +0200
s390: Align *cjump_64 and *icjump_64
During machine reorg we optimize backward jumps
https://gcc.gnu.org/g:a4abda934aa426137f059934629d3241f008e113
commit r15-2060-ga4abda934aa426137f059934629d3241f008e113
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 11:23:10 2024 +0200
s390: Fix unresolved iterators bhfgq and xdee
Code attribute bhfgq is missing a
I just ran into an unresolved iterator
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657360.html
which motivated me to dig into genoutput.cc where in process_template()
we already emit an error but only if the new compact syntax is used.
There is probably a reason for limiting the check to th
https://gcc.gnu.org/g:6d1095788e23c27061421c7d180209264ebb32f7
commit r15-2057-g6d1095788e23c27061421c7d180209264ebb32f7
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 10:41:46 2024 +0200
s390: Enable vcond_mask for 128-bit ops
In preparation of dropping vcond{,u,eq} optabs
https://gcc.gnu.org/g:75c0bf997d2808561451e62aa6b7ae7c8e32b9e9
commit r15-2058-g75c0bf997d2808561451e62aa6b7ae7c8e32b9e9
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 10:41:52 2024 +0200
s390: Drop vcond{,u} expanders
Optabs vcond{,u} will be removed for GCC 15. Since
https://gcc.gnu.org/g:1b575bb24a7a3d2b00197dd5deb4c26b313f442b
commit r15-2056-g1b575bb24a7a3d2b00197dd5deb4c26b313f442b
Author: Stefan Schulze Frielinghaus
Date: Tue Jul 16 10:41:41 2024 +0200
s390: Emulate vec_cmp{eq,gt,gtu} for 128-bit integers
Mode iterator V_HW enables V1TI
Code attribute bhfgq is missing a mapping for TF. This results in
unresolved iterators in assembler templates for *bswaptf.
With the TF mapping added the base mnemonics vlbr and vstbr are not
"used" anymore but only the extended mnemonics (vlbr was
interpreted as vlbr; likewise for vstbr). There
https://gcc.gnu.org/g:5ade7afdefe7a5179c6a139103885c2cf911d9d0
commit r14-10416-g5ade7afdefe7a5179c6a139103885c2cf911d9d0
Author: Stefan Schulze Frielinghaus
Date: Sat Jul 13 08:01:59 2024 +0200
s390: Fix output template for movv1qi
Although for instructions MVI and MVIY it does
https://gcc.gnu.org/g:cd11413ff7c4353a3e336db415304f788d23a393
commit r14-10415-gcd11413ff7c4353a3e336db415304f788d23a393
Author: Stefan Schulze Frielinghaus
Date: Sat Jul 13 08:01:51 2024 +0200
s390: Align *cjump_64 and *icjump_64
During machine reorg we optimize backward jumps
https://gcc.gnu.org/g:61715e9340ab8941d40d62158fe437e9dbe3e068
commit r15-2002-g61715e9340ab8941d40d62158fe437e9dbe3e068
Author: Stefan Schulze Frielinghaus
Date: Fri Jul 12 13:42:08 2024 +0200
s390: Fully exploit vgm, vgbm, vrepi
Currently instructions vgm and vrepi are utilized
https://gcc.gnu.org/g:e6680d3f392f7f7cc2a1515276213e21e9eeab1c
commit r15-2001-ge6680d3f392f7f7cc2a1515276213e21e9eeab1c
Author: Stefan Schulze Frielinghaus
Date: Fri Jul 12 13:40:19 2024 +0200
s390: Fix output template for movv1qi
Although for instructions MVI and MVIY it does
https://gcc.gnu.org/g:56de68aba6cb9cf3022d9e303eec6c6cdb49ad4d
commit r15-1999-g56de68aba6cb9cf3022d9e303eec6c6cdb49ad4d
Author: Stefan Schulze Frielinghaus
Date: Fri Jul 12 13:27:08 2024 +0200
s390: Align *cjump_64 and *icjump_64
During machine reorg we optimize backward jumps
On Thu, Jul 11, 2024 at 07:32:17PM +0200, Stefan Schulze Frielinghaus wrote:
> On Thu, Jul 11, 2024 at 05:14:58PM +0200, Jakub Jelinek wrote:
> > On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus wrote:
> > > I didn't have the schedule for 11.5 RC in min
On Thu, Jul 11, 2024 at 05:14:58PM +0200, Jakub Jelinek wrote:
> On Thu, Jul 11, 2024 at 05:09:41PM +0200, Stefan Schulze Frielinghaus wrote:
> > I didn't have the schedule for 11.5 RC in mind which is tomorrow and the
> > release a week afterwards. I hope this is still
On Thu, Jul 11, 2024 at 04:29:19PM +0200, Stefan Schulze Frielinghaus wrote:
> During machine reorg we optimize backward jumps and transform insns as
> e.g.
>
> (jump_insn 118 117 119 (set (pc)
> (if_then_else (ne (reg:CCRAW 33 %cc)
>
During machine reorg we optimize backward jumps and transform insns as
e.g.
(jump_insn 118 117 119 (set (pc)
(if_then_else (ne (reg:CCRAW 33 %cc)
(const_int 8 [0x8]))
(label_ref 134)
(pc))) "dec_math_1.f90":204:8 discrim 1 2161 {*cjump_64}
(expr
Currently instructions vgm and vrepi are utilized only for constant
vectors where the element mode equals the element mode of the
corresponding instruction. This patch lifts this restriction by making
use of those instructions for constant vectors even if element modes
do not coincide. For exampl
Although for instructions MVI and MVIY it does not make a difference
whether the immediate is interpreted as signed or unsigned, GAS expects
unsigned immediates for instruction format SI_URD.
gcc/ChangeLog:
* config/s390/vector.md (mov): Fix output template for
movv1qi.
---
Boots
h is why I would like to make sure that
this patch lands first and included it in this series.
Stefan Schulze Frielinghaus (3):
s390: Emulate vec_cmp{eq,gt,gtu} for 128-bit integers
s390: Enable vcond_mask for 128-bit ops
s390: Drop vcond{,u} expanders
gcc/config/s390/vector.md
Optabs vcond{,u} will be removed for GCC 15. Since regtest shows no
fallout, dropping the expanders, now.
gcc/ChangeLog:
PR target/114189
* config/s390/vector.md (V_HW2): Remove.
(vcond): Remove.
(vcondu): Remove.
---
Bootstrapped and regtested on s390. Ok for m
Mode iterator V_HW enables V1TI for target VXE which means
vec_cmpv1tiv1ti becomes available which leads to an ICE since there is
no corresponding insn.
Fixed by emulating comparisons and enabling mode V1TI unconditionally
for V_HW. For the sake of symmetry, I also added TI mode to V_HW since
TF
In preparation of dropping vcond{,u,eq} optabs
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654690.html
enable 128-bit operands for vcond_mask---including integer as well as
floating point.
This fixes partially PR115519 w.r.t. autovec-long-double-signaling-*.c
tests.
gcc/ChangeLog:
On Fri, Jun 28, 2024 at 11:46:08AM +0200, Georg-Johann Lay wrote:
> Am 27.06.24 um 10:51 schrieb Stefan Schulze Frielinghaus:
> > On Thu, Jun 27, 2024 at 09:45:32AM +0200, Georg-Johann Lay wrote:
> > > Am 24.05.24 um 11:13 Am 25.06.24 um 16:03 schrieb Paul Koning:
> > >
https://gcc.gnu.org/g:187eeb99ec5289538923668de9d61a3138376817
commit r15-1695-g187eeb99ec5289538923668de9d61a3138376817
Author: Stefan Schulze Frielinghaus
Date: Thu Jun 27 15:46:24 2024 +0200
s390: Check for ADDR_REGS in s390_decompose_addrstyle_without_index
An explicit check
On Thu, Jun 27, 2024 at 09:45:32AM +0200, Georg-Johann Lay wrote:
>
>
> Am 24.05.24 um 11:13 Am 25.06.24 um 16:03 schrieb Paul Koning:
> >
> >
> > > On Jun 24, 2024, at 1:50 AM, Stefan Schulze Frielinghaus
> > > wrote:
> > >
> > > Pi
On Wed, Jun 26, 2024 at 11:10:38AM -0400, Paul Koning wrote:
>
>
> > On Jun 26, 2024, at 8:54 AM, Stefan Schulze Frielinghaus
> > wrote:
> >
> > On Tue, Jun 25, 2024 at 01:02:39PM -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
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
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 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:
> >>
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 Sat, Jun 22, 2024 at 01:00:54PM +0200, Georg-Johann Lay wrote:
> Am 22.06.24 um 10:46 schrieb Stefan Schulze Frielinghaus:
> > On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
> > >
> > >
> > > Am 17.06.24 um 21:13 schrieb Stefan Schulze
On Fri, Jun 21, 2024 at 09:50:43PM +0200, Georg-Johann Lay wrote:
>
>
> Am 17.06.24 um 21:13 schrieb Stefan Schulze Frielinghaus via Gcc:
> > Hi all,
> >
> > I'm trying to add an alternative to an existing insn foobar:
> >
> > (defi
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):
Hi all,
I'm trying to add an alternative to an existing insn foobar:
(define_insn "foobar"
[(set (match_operand ...)
(match_operand ...))]
""
"@
foo
bar
#")
Since the asm output depends on the operands in a non-trivial way which isn't
easily solved via iterators, I went fo
On Mon, Jun 17, 2024 at 08:16:34AM +0200, Richard Biener wrote:
> On Mon, 17 Jun 2024, Kewen.Lin wrote:
>
> > Hi Richi,
> >
> > on 2024/6/14 18:31, Richard Biener wrote:
> > > The following retires vcond{,u,eq} optabs by stopping to use them
> > > from the middle-end. Targets instead (should) im
https://gcc.gnu.org/g:0ed63e3791345a9933cbbf28594ab5549d336bd4
commit r14-10317-g0ed63e3791345a9933cbbf28594ab5549d336bd4
Author: Stefan Schulze Frielinghaus
Date: Mon Jun 17 08:52:28 2024 +0200
s390: testsuite: Fix ifcvt-one-insn-bool.c
With the change of r15-787-g57e04879389f9c
https://gcc.gnu.org/g:8f124e6b79daa43618dbb1e67c09629676d07396
commit r14-10316-g8f124e6b79daa43618dbb1e67c09629676d07396
Author: Stefan Schulze Frielinghaus
Date: Mon Jun 17 08:52:20 2024 +0200
s390: Implement TARGET_NOCE_CONVERSION_PROFITABLE_P [PR109549]
Consider a NOCE
https://gcc.gnu.org/g:e86d4e4ac7d7438f2f1b2437508cfd394a0a34d9
commit r15-1367-ge86d4e4ac7d7438f2f1b2437508cfd394a0a34d9
Author: Stefan Schulze Frielinghaus
Date: Mon Jun 17 08:46:38 2024 +0200
s390: Delete mistakenly added tests
gcc/testsuite/ChangeLog
https://gcc.gnu.org/g:9965acb77cbd686283a9d0a867c80b1e710f46b9
commit r15-1366-g9965acb77cbd686283a9d0a867c80b1e710f46b9
Author: Stefan Schulze Frielinghaus
Date: Mon Jun 17 08:37:11 2024 +0200
s390: Extend two element float vector
This implements a V2SF -> V2DF ext
https://gcc.gnu.org/g:2ab143df110a40bd41b5368ef84819953bf971b1
commit r15-1365-g2ab143df110a40bd41b5368ef84819953bf971b1
Author: Stefan Schulze Frielinghaus
Date: Mon Jun 17 08:36:11 2024 +0200
s390: Extend two/four element integer vectors
For the moment I deliberately left out
1 - 100 of 428 matches
Mail list logo
