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?
gcc/ChangeLog:
* config/s390/predicates.md (execute_operation): Us
In addition to the existing check also ask the target whether a
replacement register may be accessed in a different mode than it was set
before.
Bootstrapped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* regcprop.c (find_oldest_value_reg): Ask target whether
differ
oads from p[i] where i>0. Maybe
there are more generic solutions to express this in contrast to my current one?
Thanks again for your input so far. Really appreciated.
Cheers,
Stefan
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8a5fb3fd99c..7b2d7405277 100644
--- a/gcc/Makefile.in
ping
On Tue, Mar 16, 2021 at 06:13:21PM +0100, Stefan Schulze Frielinghaus wrote:
> [snip]
>
> Please find attached a new version of the patch. A major change compared to
> the previous patch is that I created a separate pass which hopefully makes
> reviewing also easier since it
Bootstraped and regtested on IBM Z. Ok for mainline?
gcc/ChangeLog:
* config/s390/s390.md ("*movdi_31", "*movdi_64"): Add
alternative in order to load a DFP zero.
---
gcc/config/s390/s390.md | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
dif
Regarding test gcc.dg/pr93210.c, on different targets GIMPLE code may
slightly differ which is why the scan-tree-dump-times directive may
fail. For example, for a RETURN_EXPR on x86_64 we have
return 0x11100f0e0d0c0a090807060504030201;
whereas on IBM Z the first operand is a RESULT_DECL like
For z10 and newer inner loops are completely unrolled which leaves no
inner loops to jam which renders this testcase to fail. Reverting
max-completely-peel-times to the default value fixes this testcase.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-and-jam.c: Revert max-completely-peel-times
On s390* the only missing part for the mentioned testcases was a load of
a double floating-point zero via a move (in particular for quite old
machines) which was added in commit 46c47420a5fefd4d9d02b0db347235dd74e20fb2.
Common code implementation is sufficient in order to clear volatile
GPRs, FPRs,
For z10 and newer inner loops are completely unrolled which means store
motion is not applied. Reverting max-completely-peeled-insns to the
default value fixes these testcases.
Ok for mainline?
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr83403-1.c: Revert
max-completely-peeled-
Depending on whether GCC is configured using --with-mode=zarch or not,
for the 31bit target instructions are generated either for ESA or
z/Architecture. For the sake of simplicity and robustness test only for
the latter by adding manually option -mzarch.
gcc/testsuite/ChangeLog:
* gcc.ta
On IBM Z the aliasing stores are realized through one element vector
instructions, if no cost model for vectorization is used which is the
default according to vect.exp. Fixed by changing the number of times
the pattern must be found in the dump.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb
The test fails for targets with V4QImode support which is the case for
IBM Z.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr71264.c: Xfail on IBM Z due to V4QImode support.
Ok for mainline?
---
gcc/testsuite/gcc.dg/vect/pr71264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze Frielinghaus wrote:
[...]
> > but we won't ever arrive here because of the niters condition. But
> > yes, doing the pattern matching in the innermost loop processing code
> > looks good to me - for the sp
On Wed, Jun 16, 2021 at 04:22:35PM +0200, Richard Biener wrote:
> On Mon, Jun 14, 2021 at 7:26 PM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Thu, May 20, 2021 at 08:37:24PM +0200, Stefan Schulze Frielinghaus wrote:
> > [...]
> > > > but we won'
401 - 414 of 414 matches
Mail list logo
