https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #18 from Dominik Vogt ---
Defining PROMOTE_MODE is not really an option on S/390. Whether it's
profitable or expensive to promote a value mostly depends on the way a value is
used and the context. Experiments with using PROMOTE_MODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #17 from Dominik Vogt ---
Lookin gat some other test program I've immediately seen cases that introduce
sign extension instructions in code that worked without them before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #16 from Andreas Krebbel ---
(In reply to Dominik Vogt from comment #15)
> Providing that macro does fix the problem:
>
> #define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
> if (GET_MODE_CLASS (MODE) == MODE_INT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #15 from Dominik Vogt ---
Providing that macro does fix the problem:
#define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
if (GET_MODE_CLASS (MODE) == MODE_INT \
&& GET_MODE_SIZE (MODE) < (TARGET_ZARCH ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #14 from Alexandre Oliva ---
The reason we don't coalesce on s390 is that there's no PROMOTE_MODE defined
there, so i_1 and j_2 promote to SImode, whereas x_3 and y_4, being function
arguments, promote to DImode as per s390_promote_fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #13 from Dominik Vogt ---
Could you give me a hint which dump files to look at?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #12 from Richard Biener ---
So for some reason no SSA coalescing is done for s390x here (compared to
x86_64).
That's the thing to look at, possibly related to some of the required parameter
coalescing / default def coalescing hackery.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #11 from Richard Biener ---
(In reply to Segher Boessenkool from comment #4)
> RA assigns registers so that one of the two moves under the if
> becomes a nop, and then bb-reorder duplicates the code.
And then nothing cleans up the us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #10 from Dominik Vogt ---
Created attachment 36920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36920&action=edit
BAD annotated assembly file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #8 from Dominik Vogt ---
Created attachment 36918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36918&action=edit
BAD expand dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #9 from Dominik Vogt ---
Created attachment 36919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36919&action=edit
BAD ce1 dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #7 from Dominik Vogt ---
Created attachment 36917
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36917&action=edit
GOOD annotated assembly file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #6 from Dominik Vogt ---
Created attachment 36916
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36916&action=edit
GOOD ce1 dump
Is this the correct file for the ifcvt output?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #5 from Dominik Vogt ---
Created attachment 36915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36915&action=edit
GOOD expand dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #3 from Richard Biener ---
And with -fno-if-conversion on x86_64 I see
foo:
.LFB0:
.cfi_startproc
cmpl%esi, %edi
jle .L2
movl%edx, %esi
movl%edx, %edi
.L2:
movl%edi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #2 from Richard Biener ---
On x86_64 the testcase produces
foo:
.LFB0:
.cfi_startproc
cmpl%esi, %edi
movl%edx, %ecx
movl%edx, %eax
cmovle %esi, %ecx
cmovle %edi, %eax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
Richard Biener changed:
What|Removed |Added
Component|regression |tree-optimization
Target Milestone|--
18 matches
Mail list logo
