On 9/11/23 08:56, Stefan Schulze Frielinghaus wrote:
> On Mon, Aug 28, 2023 at 11:33:37AM +0200, Andreas Krebbel wrote:
>> Hi Stefan,
>>
>> do you really need to introduce a new flag for U64 given that the type of
>> the builtin is unsigned long?
>
> In function s390_const_operand_ok the
Hi Stefan,
do you really need to introduce a new flag for U64 given that the type of the
builtin is unsigned long?
Andreas
On 8/21/23 17:56, Stefan Schulze Frielinghaus wrote:
> The second argument of these builtins is an unsigned immediate. For
> vec_rli the API allows immediates up to 64
On 8/21/23 17:58, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390-builtins.def (s390_vec_signed_flt): Fix
> builtin flag.
> (s390_vec_unsigned_flt): Ditto.
> (s390_vec_revb_flt): Ditto.
>
On 8/3/23 08:51, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on s390x. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (expand_perm_as_a_vlbr_vstbr_candidate):
> New function which handles bswap patterns for vec_perm_const.
>
On 8/3/23 08:48, Stefan Schulze Frielinghaus wrote:
> This enables the following tests which rely on instruction vperm which
> is available since z13 with the initial vector support.
>
> testsuite/gcc.dg/vect/vect-bswap16.c
> 42:/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" {
The IBM Z ELF ABI mandates every symbol to reside on a 2 byte boundary
in order to be able to use the larl instruction. However, in some
situations it is difficult to enforce this, e.g. for common linker
scripts as used in the Linux kernel. This patch introduces the
-munaligned-symbols option.
On 7/17/23 17:09, Juergen Christ wrote:
> A vec_cmpge produces a negation. Replace this negation by swapping the two
> selection choices of a vec_sel based on the result of the vec_cmpge.
>
> Bootstrapped and regression tested on s390x.
>
> gcc/ChangeLog:
>
> *
On 7/7/23 15:51, Juergen Christ wrote:
> Do not reinitialize vector lanes to zero since they are already initialized to
> zero.
>
> Bootstrapped and regression tested on s390x.
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (vec_init): Fix default case
>
> gcc/Testsuite/ChangeLog:
>
>
A change we have committed back in 2015 relies on the backend
requested ABI alignment to be applied to ALL symbols by the
middle-end. However, this does not appear to be the case for external
symbols. With this commit we assume all symbols without explicit
alignment to be aligned according to the
On 3/20/23 07:33, Kewen.Lin wrote:
> Hi,
>
> One of my workmates found there is a warning like:
>
> libgcc/config/rs6000/morestack.S:402: Warning: ignoring
> incorrect section type for .init_array.0
>
> when compiling libgcc/config/rs6000/morestack.S.
>
> Since commit r13-6545
On 5/16/23 08:43, Stefan Schulze Frielinghaus wrote:
> So far atomic objects are aligned according to their default alignment.
> For 128 bit scalar types like int128 or long double this results in an
> 8 byte alignment which is wrong and must be 16 byte.
>
> libstdc++ already computes a correct
On 5/15/23 09:17, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested. Ok for mainline?
>
> Stefan Schulze Frielinghaus (3):
> s390: Refactor block operation cpymem
> s390: Add block operation movmem
> s390: Refactor block operation setmem
>
> gcc/config/s390/s390-protos.h
On 3/2/23 19:13, Robin Dapp wrote:
> Hi,
>
> we seem to flip flop between the "high" and "not low" variants of load on
> condition. Accept both in the affected test cases.
>
> Going to commit this as obvious.
>
> Regards
> Robin
>
> --
>
> gcc/testsuite/ChangeLog:
>
> *
On 3/2/23 16:24, Stefan Schulze Frielinghaus wrote:
> This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
> introducing a runtime check for alignment for 16 byte atomic
> compare-exchange, load, and store.
>
> Bootstrapped and regtested on s390.
> Ok for mainline and
On 3/2/23 19:17, Robin Dapp wrote:
> Hi,
>
> When compiling on a system where binutils do not yet support the 'z16'
> name assembling fails with -march=native which we currently interpret
> as -march=z16 (on a z16 machine). This patch uses -march=arch14
> instead.
>
> Is it OK?
Ok. Thanks!
On 2/27/23 11:13, Robin Dapp wrote:
>> Do you really need a copy of the address register? Couldn't you just do a
>> src = adjust_address (operands[1], BLKmode, 0);
>> You create a paradoxical subreg of the QImode input but vll actually
>> uses the whole 32 bit value. Couldn't we end up with
On 2/11/23 16:59, Stefan Schulze Frielinghaus wrote:
> So far we propagate scheduler state across basic blocks within EBBs and
> reset the state otherwise. In certain circumstances the entry block of
> an EBB might be empty, i.e., no_real_insns_p is true. In those cases
> scheduler state is not
On 2/11/23 17:10, Stefan Schulze Frielinghaus wrote:
> Use constrain_operands in order to check whether there exists a valid
> alternative instead of extract_constrain_insn which ICEs in case no
> alternative is found.
>
> Bootstrapped and regtested on IBM zSystems. Ok for mainline?
>
>
On 2/2/23 09:43, Robin Dapp wrote:
> Hi,
>
> this patch adds LEN_LOAD/LEN_STORE support for z14 and newer.
> It defines a bias value of -1 and implements the LEN_LOAD and LEN_STORE
> optabs.
>
> It also includes various vll/vstl testcases adapted from Kewen Lin's patch
> for Power.
>
>
With this patch a scheduling barrier is created to prevent the insn
setting up the frame-pointer and instructions which save GPRs to the
stack to be swapped. Otherwise broken CFI information would be
generated since the stack save insns would use a base register which
is not currently declared as
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments without having to rely on debug information.
With the -mpreserve-args option
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments without having to rely on debug information.
With the -mpreserve-args option
On 1/24/23 09:47, Stefan Schulze Frielinghaus wrote:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
>
On 12/27/22 19:23, Jeff Law wrote:
>
>
> On 12/13/22 01:55, Andreas Krebbel via Gcc-patches wrote:
>> Hi,
>>
>> I need a way to save registers on the stack and generate proper CFI for it.
>> Since I do not intend to
>> restore them I needed a wa
Bootstrapped and regression tested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390.md (*not): New pattern.
gcc/testsuite/ChangeLog:
* gcc.target/s390/not.c: New test.
---
gcc/config/s390/s390.md | 8
gcc/testsuite/gcc.target/s390/not.c
Committed to mainline. Bootstrap and regression tests are clean.
gcc/ChangeLog:
* config/s390/s390.cc (s390_register_info): Check call_used_regs
instead of hard-coding the register numbers for call saved
registers.
(s390_optimize_register_info): Likewise.
Hi,
I need a way to save registers on the stack and generate proper CFI for it.
Since I do not intend to
restore them I needed a way to tell the CFI generation step about it:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606128.html
Is this ok for mainline?
Bye,
Andreas
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments.
With the -mpreserve-args option GPRs and FPRs are save to the stack
slots
This patch introduces a new reg note which can be used to tell the CFI
verification in dwarf2cfi that a register is stored without intending
to restore from it.
This is useful when storing e.g. register contents to the stack and
generate CFI for it although the register is not really supposed to
This adds support for preserving the content of parameter registers to
the stack and emit CFI for it. This useful for applications which want
to implement their own stack unwinding and need access to function
arguments.
A small common code patch was needed to prevent the CFI verification
in
On 8/17/22 13:50, Stefan Schulze Frielinghaus wrote:
> For a parameter with BLKmode we cannot use REG_NREGS in order to
> determine the number of consecutive registers. Streamlined this with
> the implementation of s390_function_arg.
>
> Fix some indentation whitespace, too.
>
> Assuming
On 10/19/22 08:22, Robin Dapp wrote:
> Hi,
>
> since r13-2746 we hit an ICE when bootstrapping with -m31 and
> --enable-checking=all.
>
> ../../../../libgfortran/ieee/ieee_helper.c: In function
> 'ieee_class_helper_16':
> ../../../../libgfortran/ieee/ieee_helper.c:77:3: internal compiler
>
On 8/22/22 17:10, Robin Dapp wrote:
> Hi,
>
> after discussing off-list, here is v2 of the patch. We now recognize if
> the permutation mask only refers to the first or the second operand and
> use this later when emitting vpdi.
>
> Regtested and bootstrapped, no regressions.
>
> Is it OK?
>
On 8/12/22 16:48, Robin Dapp wrote:
> Hi,
>
> similar to other backends this patch implements vec_set via
> vec_merge and vec_duplicate instead of an unspec. This opens up
> more possibilites to combine instructions.
>
> Bootstrapped and regtested. No regressions.
>
> Is it OK?
>
> Regards
>
On 8/12/22 16:19, Robin Dapp wrote:
> Hi,
>
> vec_select can handle dynamic/runtime masks nowadays. Therefore we can
> get rid of the UNSPEC_VEC_EXTRACT that was preventing further
> optimizations like combining instructions with vec_extract patterns.
>
> Bootstrapped and regtested. No
On 8/12/22 12:13, Robin Dapp wrote:
> Hi,
>
> swapping the two elements of a V2DImode or V2DFmode vector can be done
> with vpdi instead of using the generic way of loading a permutation mask
> from the literal pool and vperm.
>
> Analogous to the V2DI/V2DF case reversing the elements of a
On 8/12/22 12:02, Robin Dapp wrote:
> Hi,
>
> this patch tries to be more explicit by mentioning z15 in s390_issue_rate.
>
> No changes in testsuite, bootstrap or SPEC obviously.
>
> Is it OK?
>
> Regards
> Robin
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_issue_rate): Add z15.
On 8/12/22 12:00, Robin Dapp wrote:
> Hi,
>
> inspired by Power we also introduce -munroll-only-small-loops. This
> implies activating -funroll-loops and -munroll-only-small-loops at -O2
> and above.
>
> Bootstrapped and regtested.
>
> This introduces one regression in
On 8/10/22 13:42, Ilya Leoshkevich wrote:
> On Wed, 2022-08-03 at 12:20 +0200, Ilya Leoshkevich wrote:
>> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>>
>>
>>
>> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
>> produces an insn that vsel is supposed to
On 8/3/22 12:20, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
> produces an insn that vsel is supposed to recognize, but can't,
> because it's not defined for V2SF. Fix by
This avoids generating illegal (strict_low_part (reg ...)) RTXs. This
required two changes:
1. Do not use gen_lowpart to generate the inner expression of a
STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because
there is already a paradoxical subreg or because it can directly be
On 4/13/22 09:30, Richard Biener via Gcc wrote:
>
> Status
> ==
>
> The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> candidate and the GCC 11.3 release next week. All changes now require
> release manager approval.
Hi,
I would like to push:
On 4/13/22 12:23, Robin Dapp wrote:
> Hi,
>
> this patch adds the scheduler description for z16. Bootstrapped and
> regtested with --with-arch=z16.
>
> Is it OK?
>
> Regards
> Robin
>
>
> gcc/ChangeLog:
>
> * config/s390/s390.cc (s390_get_sched_attrmask): Add z16.
>
On 4/13/22 09:35, Robin Dapp wrote:
> Hi,
>
> this test case checks that we do not ICE but FAILs because of
> -Wint-to-pointer-cast. Silence this warning.
>
> Is it OK?
Ok. Thanks!
Andreas
On 4/14/22 05:10, Kewen.Lin wrote:
> Hi,
>
> The test case pr105250.c is like its related pr105140.c, which
> suffers the error with message like "{AltiVec,vector} argument
> passed to unprototyped" on powerpc and s390. So like commits
> r12-8025 and r12-8039, this fix is to add the dg-skip-if
So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.
gcc/ChangeLog:
* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc
v2:
- Remove redundant num_zero_width_bf_seen and num_fields_seen
tracking. (Thanks Stefan Schulze-Frielinghaus)
Re-tested with testsuite and ABI tests.
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in
On 4/6/22 17:32, Segher Boessenkool wrote:
> This test fails with error "AltiVec argument passed to unprototyped
> function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
> from 2005) actually tests for any vector type argument. It also does
> not fail on Darwin, not reflected here
On 4/4/22 13:52, Robin Dapp wrote:
> Hi,
>
> some tests expect a convert instruction but nowadays the conversion is
> already done at compile time. This results in a literal-pool load.
> Change the tests accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
>
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> we have been emitting the "higher" variantes instead of the "not less or
> equal" ones for a while. Change the test expectations accordingly.
>
> OK for trunk?
>
> Regards
> Robin
>
> gcc/testsuite/ChangeLog:
>
> *
On 4/4/22 13:51, Robin Dapp wrote:
> Hi,
>
> in gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free. On
> s390 the test's while loop is converted into a rawmemchr builtin making
> it impossible to determine that the pointers *p and *q are related.
>
> Therefore, disable the tree loop
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in an FPR only if it has
exactly one member. On the other hand it says that structs of 1,2,4,8
bytes are passed in a GPR. So this struct is expected to be passed
On 3/5/22 09:33, Jakub Jelinek wrote:
> Hi!
>
> The following testcase fails to assemble due to clgte %r6,0(%r1,%r10)
> insn not being accepted by assembler.
> My rough understanding is that in the RSY-b insn format the spot
> in other formats used for index registers is used instead for M3 what
On 2/25/22 12:38, Robin Dapp wrote:
> Hi,
>
> the IF_THEN_ELSE detection currently prevents us from properly costing
> register-register moves which causes the lower-subreg pass to assume
> that a VR-VR move is as expensive as two GPR-GPR moves.
>
> This patch adds handling for SETs containing
On 2/7/22 09:11, Jakub Jelinek wrote:
...
> 1) formatting, = should be at the start of next line rather than end of the
>line
> 2) all_masks, always_inline_safe_masks and caller_required_masks aren't
>ever modified, perhaps make them const?
> 3) I wonder if there is any advantage to have
MASK_MVCLE is set for -Os but not for other optimization levels. In
general it should not make much sense to inline across calls where the
flag is different but we have to allow it for always_inline.
The patch also rearranges the hook implementation a bit based on the
recommendations from Jakub
On 2/2/22 12:57, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for
> releases/gcc-11?
>
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section
On 2/1/22 21:49, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
> s390_code_end () puts indirect branch tables into separate sections and
> tries to switch back to wherever it was in the beginning by calling
> switch_to_section
When propagating a multi-word register into an access with a smaller
mode the can_change_mode backend hook is already consulted for the
original register. This however is also required for the intermediate
copy in copy_regno which might use a different register class.
Bootstrapped on x86_64 and
On 1/20/22 11:10, Robin Dapp wrote:
> Hi,
>
> this patch is a follow-up patch to the recent ifcvt changes. It
> increased costs for a load on condition to 6. This ensures that we
> if-convert sequences of three regular instructions (of cost 4) e.g. a
> compare and two SETs into two loads on
On 1/20/22 17:13, Robin Dapp wrote:
> Hi,
>
> this patch splits the CCSmode into an integer and a floating point
> variant. This allows ifcvt to consider floating point compares which
> would be rejected before because they could not be reversed.
>
> Bootstrapped and regtested on s390x.
>
> Is
On 1/20/22 23:52, Richard Sandiford wrote:
> cc:ing the x86 and s390 maintainers
>
> soeren--- via Gcc-patches writes:
>> From: Sören Tempel
>>
>> The -fsplit-stack option requires the pthread_t TCB definition in the
>> libc to provide certain struct fields at specific hardcoded offsets. As
>>
On 1/14/22 20:41, Andreas Krebbel via Gcc-patches wrote:
> On 1/14/22 08:37, Richard Biener wrote:
> ...
>> Can the gist of this bug be put into the GCC bugzilla so the rev can
>> refer to it?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
>
>> Can we have a
On 1/14/22 08:37, Richard Biener wrote:
...
> Can the gist of this bug be put into the GCC bugzilla so the rev can
> refer to it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
> Can we have a testcase even?
The testcase from Jakub is in the BZ. However, since it doesn't fail with head
I
On 1/13/22 18:11, Andreas Krebbel via Gcc-patches wrote:
...
> @@ -5949,7 +5959,7 @@ register if floating point arithmetic is not being
> done. As long as the\n\
> floating registers are not in class @code{GENERAL_REGS}, they will not\n\
> be used unless some pattern's constraint
The cprop_hardreg pass is built around the assumption that accessing a
register in a narrower mode is the same as accessing the lowpart of
the register. This unfortunately is not true for vector registers on
IBM Z. This caused a miscompile of LLVM with GCC 8.5. The problem
could not be reproduced
On 11/19/21 10:45, Stefan Schulze Frielinghaus wrote:
...
> diff --git a/gcc/testsuite/gcc.target/s390/2029.c
> b/gcc/testsuite/gcc.target/s390/2029.c
> new file mode 100644
> index 000..1a6df4f4b89
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/s390/2029.c
> @@ -0,0 +1,12
On 11/5/21 20:34, Jeff Law wrote:
>
>
> On 11/5/2021 4:19 AM, Andreas Krebbel via Gcc-patches wrote:
>> This prevents find_cond_trap from being invoked after reload. It may
>> generate compares which would require reloading.
>>
>> Bootstrapped and reg
This prevents find_cond_trap from being invoked after reload. It may
generate compares which would require reloading.
Bootstrapped and regression tested on s390x.
Ok for mainline?
gcc/ChangeLog:
PR rtl-optimization/103028
* ifcvt.c (find_if_header): Invoke find_cond_trap only
With -fstack-check the stack probes emitted access memory below the
stack pointer.
Bootstrapped and regression tested on s390x.
Committed to mainline
gcc/ChangeLog:
* config/s390/s390.h (STACK_CHECK_MOVING_SP): New macro
definition.
---
gcc/config/s390/s390.h | 5 +
1 file
On 11/2/21 18:31, Stefan Schulze Frielinghaus wrote:
> Bootstrapped and regtested on IBM Z. Ok for mainline?
>
> gcc/ChangeLog:
>
> * config/s390/s390.c (s390_loop_unroll_adjust): In case of early
> exit free bbs.
Ok. Thanks!
Andreas
On 11/2/21 15:54, Stefan Schulze Frielinghaus wrote:
> The tests require vector extensions which are only available for z13 and
> later while using the z/Architecture.
>
> Bootstrapped and regtested on IBM Z. Ok for mainline?
>
> gcc/testsuite/ChangeLog:
>
> *
On 10/30/21 12:43, Stefan Schulze Frielinghaus wrote:
> Since a recent enhancement of -Waddress a couple of warnings are emitted
> and turned into errors during bootstrap:
>
> gcc/config/s390/s390.md:12087:25: error: the address of 'operands' will never
> be NULL [-Werror=address]
> 12087 |
On 10/8/21 16:23, Stefan Schulze Frielinghaus wrote:
> On Thu, Oct 07, 2021 at 11:16:24AM +0200, Andreas Krebbel wrote:
>> On 9/20/21 11:24, Stefan Schulze Frielinghaus wrote:
>>> This patch implements the rawmemchr expander as introduced in
>>>
On 9/20/21 11:24, Stefan Schulze Frielinghaus wrote:
> This patch implements the rawmemchr expander as introduced in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579649.html
>
> Bootstrapped and regtested in conjunction with the patch from above on
> IBM Z. Ok for mainline?
>
>
On 9/30/21 10:50, Ilya Leoshkevich wrote:
> Hi,
>
> This series contains a backport of kpatch changes needed to support
> https://github.com/dynup/kpatch/pull/1203 so that it could be used in
> RHEL 9. The patches have been in master for 4 months now without
> issues.
>
> Bootstrapped and
The code sequence emitted uses CC internally.
gcc/ChangeLog:
* config/s390/tpf.md (prologue_tpf, epilogue_tpf): Add cc clobber.
---
gcc/config/s390/tpf.md | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/s390/tpf.md b/gcc/config/s390/tpf.md
index
Avoid emitting a strict low part move if the insv target actually
affects the whole target reg.
Bootstrapped and regression tested on s390x.
gcc/ChangeLog:
PR target/10
* config/s390/s390.c (s390_expand_insv): Emit a normal move if it
is actually a full copy of the
This patch gets rid of the unspecs we were using for the vector merge
instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390-modes.def: Add more vector modes to support
concatenation of two vectors.
* config/s390/s390-protos.h
gcc/ChangeLog:
* config/s390/vector.md (V_HW_64): Remove mode iterator.
(*vec_load_pair): Use V_HW_2 instead of V_HW_64.
* config/s390/vx-builtins.md
(vec_scatter_element_SI): Use V_HW_2 instead of
V_HW_64.
---
gcc/config/s390/vector.md | 7 +++
The patch gets rid of the unspec used for the vector permute double
immediate instruction and replaces it with generic rtx.
gcc/ChangeLog:
* config/s390/s390.md (UNSPEC_VEC_PERMI): Remove constant
definition.
* config/s390/vector.md (*vpdi1, *vpdi4): New pattern
This patchset, after some prep work, provides an initial
implementation of the TARGET_VECTORIZE_VEC_PERM_CONST hook for IBM Z.
Only the vmrh, vmrl, and vpdi instruction are exploited so far. More
instructions will be added with follow-on patches.
Bootstrapped and regression tested on s390x.
As
This patch makes use of the vector permute double immediate
instruction for constant permute vectors.
gcc/ChangeLog:
* config/s390/s390.c (expand_perm_with_vpdi): New function.
(vectorize_vec_perm_const_1): Call expand_perm_with_vpdi.
* config/s390/vector.md (*vpdi1,
This patch implements the TARGET_VECTORIZE_VEC_PERM_CONST in the IBM Z
backend. The initial implementation only exploits the vector merge
instruction but there is more to come.
gcc/ChangeLog:
* config/s390/s390.c (MAX_VECT_LEN): Define macro.
(struct expand_vec_perm_d): Define
On 7/23/21 2:47 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/global-array-element-pic2.c: Add -mzarch, add
> an expectation for 31-bit mode.
> *
On 7/28/21 9:43 AM, Richard Biener wrote:
> On Wed, Jul 28, 2021 at 8:44 AM Andreas Krebbel via Gcc-patches
> wrote:
>>
>> There are also memory operands passed for in0 and in1.
>>
>> Ok for mainline?
>
> They can also be constant vectors, I'd just not
On 7/27/21 10:04 PM, Ilya Leoshkevich via Gcc-patches wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> libsanitizer/ChangeLog:
>
> * configure.tgt (s390*-*-linux*): Enable LSan and TSan for
> s390x.
Ok. Thanks!
Andreas
There are also memory operands passed for in0 and in1.
Ok for mainline?
gcc/ChangeLog:
* target.def: Describe in0 and in1 as being either register or
memory operands.
* doc/tm.texi: Regenerate.
---
gcc/doc/tm.texi | 7 ---
gcc/target.def | 7 ---
2 files
On 7/12/21 9:23 PM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573614.html
> v1 -> v2: Do not use UNSPEC_PLT in 64-bit code and rename it to
> UNSPEC_PLT31 (Ulrich, Andreas). Do
On 6/24/21 12:42 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573348.html
> v1 -> v2: Use ATTRIBUTE_UNUSED, compact op[] array (Andreas).
> I've also noticed that one of the
On 6/22/21 12:20 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> s390 glibc does not need counters in the .data section, since it stores
> edge hits in its own data structure. Therefore counters only waste
> space and confuse diffing
On 6/9/21 2:47 PM, Robin Dapp wrote:
>> I think the real problem is the expander name. That's why it could not be
>> found by optab. The second
>> mode needs to be the int vector mode of op3. With that change the testcases
>> work as expected:
>>
>> diff --git a/gcc/config/s390/vector.md
On 6/2/21 4:21 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
>
>
>
> Since commit dd1ef00c45ba ("Fix bug in the define_subst handling that
> made match_scratch unusable for multi-alternative patterns.") the
> workaround for that bug in
_Bool needs to be defined as macro in order to trigger the
context-sensitive macro expansion mechanism.
Bootstrapped and regtested on s390x.
Committed to mainline.
gcc/ChangeLog:
* config/s390/s390-c.c (s390_cpu_cpp_builtins_internal): Define
_Bool as macro expanding to _Bool.
v1 -> v2: build_reference_type_for_mode and build_pointer_type_for_mode now
pick pointer mode if
MODE argument is VOIDmode.
Bootstrapped and regression tested on x86_64 and s390x.
Ok for mainline and GCC 11?
Andreas
gcc/cp/ChangeLog:
PR c++/100281
* cvt.c
Ping
On 4/30/21 8:32 AM, Andreas Krebbel via Gcc-patches wrote:
> The problem appears to be triggered by two locations in the front-end
> where non-POINTER_SIZE pointers aren't handled right now.
>
> 1. An assertion in strip_typedefs is triggered because the alignment
> of the ty
Hi Robin,
On 5/5/21 5:18 PM, Robin Dapp wrote:
...
> diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md
> index c80d582a300..7c730432d80 100644
> --- a/gcc/config/s390/vector.md
> +++ b/gcc/config/s390/vector.md
> @@ -36,6 +36,7 @@
> (define_mode_iterator V_HW2 [V16QI V8HI V4SI
On 5/4/21 5:08 PM, Robin Dapp wrote:
> Hi,
>
> instead of selecting bits 62 to (wraparound) 59 from r2 and inserting
> them into r3, we select bits 60 to 62 from r3 and insert them into r2
> nowadays. Adjust the test accordingly.
>
> Is this OK?
>
> Regards
> Robin
>
>
On 5/6/21 9:56 AM, Marius Hillenbrand wrote:
> Hi,
>
> this patch fixes the check of immediate operands to the builtin vec_permi and
> adds a new test for this built-in.
>
> Reg-rested and bootstrapped on s390x.
>
> Is it OK for master? Is it OK for backporting to gcc-11?
>
> Regards,
> Marius
1 - 100 of 196 matches
Mail list logo
