[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #14 from seurer at gcc dot gnu.org --- I tried the original full 177.mesa benchmark and it works fine after your patch. Thanks!
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- Thanks for reporting the problem and analyzing it.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Tue Oct 24 07:26:52 2017 New Revision: 254037 URL: https://gcc.gnu.org/viewcvs?rev=254037&root=gcc&view=rev Log: PR middle-end/82569 * tree-outof-ssa.h (always_initialized_rtx_for_ssa_name_p): Delete. * expr.c (expand_expr_real_1) : Revert latest change. * loop-iv.c (iv_get_reaching_def): Likewise. * cfgexpand.c (expand_one_ssa_partition): Initialize the RTX if the variable is promoted and the partition contains undefined values. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expr.c trunk/gcc/loop-iv.c trunk/gcc/tree-outof-ssa.h
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #11 from Eric Botcazou --- store_expr_with_bounds also has a special handling for promoted SUBREGs and it would probably need to be changed too. In the end, I think that the current approach of not setting SUBREG_PROMOTED_VAR_P for problematic SSA_NAME partitions isn't robust and even viable; we would need to stop promoting the RTX altogether for it to really work.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569
--- Comment #10 from Eric Botcazou ---
Index: cfgexpand.c
===
--- cfgexpand.c (revision 253921)
+++ cfgexpand.c (working copy)
@@ -3661,7 +3661,9 @@ expand_gimple_stmt_1 (gimple *stmt)
bool promoted = false;
target = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
- if (GET_CODE (target) == SUBREG && SUBREG_PROMOTED_VAR_P (target))
+ if (GET_CODE (target) == SUBREG
+ && (SUBREG_PROMOTED_VAR_P (target)
+ || TREE_CODE (lhs) == SSA_NAME))
promoted = true;
ops.code = gimple_assign_rhs_code (assign_stmt);
@@ -3693,7 +3695,16 @@ expand_gimple_stmt_1 (gimple *stmt)
;
else if (promoted)
{
- int unsignedp = SUBREG_PROMOTED_SIGN (target);
+ int unsignedp;
+
+ if (SUBREG_PROMOTED_VAR_P (target))
+ unsignedp = SUBREG_PROMOTED_SIGN (target);
+ else
+ {
+ machine_mode pmode = promote_ssa_mode (lhs, &unsignedp);
+ gcc_assert (GET_MODE (SUBREG_REG (target)) == pmode);
+ }
+
/* If TEMP is a VOIDmode constant, use convert_modes to make
sure that we properly convert it. */
if (CONSTANT_P (temp) && GET_MODE (temp) == VOIDmode)
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #9 from Eric Botcazou --- > But I don't fully understand the new issue - what are "other SUBREGs"? The > SUBREG_PROMOTED_VAR setting is set per subreg so we should be able to handle > those okish? The other SUBREGs are the SUBREGs created for a promoted variable but for which we don't set SUBREG_PROMOTED_VAR_P anymore. I guess a more sensible fix would be to do the full assignment in expand_gimple_stmt_1 for them too.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569
--- Comment #8 from Richard Biener ---
(In reply to Eric Botcazou from comment #7)
> It's a conflict with the out-of-ssa pass: this pass implicitly expects every
> pseudo associated with a partition to be always fully initialized, including
> a DImode pseudo for a partition attached to a SImode variable. And this is
> guaranteed for promoted SUBREGs because expand_gimple_stmt_1 makes sure
> that, if one of the them is on the LHS of an assignment, then the whole
> SUBREG_REG is assigned (with the appropriate extension). But this falls for
> other SUBREGs.
>
> So an immediate fix would be to generate the glue code between partitions
> with undefined values and other partitions in insert_partition_copy_on_edge,
> but I'm starting to wonder whether the entire approach shouldn't be scrapped
> instead.
Sounds indeed like a hack ontop of a hack :/
But I don't fully understand the new issue - what are "other SUBREGs"? The
SUBREG_PROMOTED_VAR setting is set per subreg so we should be able to handle
those okish?
Like change
temp = gen_lowpart_SUBREG (mode, decl_rtl);
/* We cannot assume anything about an existing extension if the
register may contain uninitialized bits. */
if (always_initialized_rtx)
{
SUBREG_PROMOTED_VAR_P (temp) = 1;
SUBREG_PROMOTED_SET (temp, unsignedp);
}
to
if (always_initialized_rtx
&& mode == TYPE_MODE (TREE_TYPE (exp)))
? Not sure if this captures the issue as said.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #7 from Eric Botcazou --- It's a conflict with the out-of-ssa pass: this pass implicitly expects every pseudo associated with a partition to be always fully initialized, including a DImode pseudo for a partition attached to a SImode variable. And this is guaranteed for promoted SUBREGs because expand_gimple_stmt_1 makes sure that, if one of the them is on the LHS of an assignment, then the whole SUBREG_REG is assigned (with the appropriate extension). But this falls for other SUBREGs. So an immediate fix would be to generate the glue code between partitions with undefined values and other partitions in insert_partition_copy_on_edge, but I'm starting to wonder whether the entire approach shouldn't be scrapped instead.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Eric Botcazou changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #6 from Eric Botcazou --- > This is a cut down single function test case that shows the problem. I > tried cutting out more but it changed how the code was generated too much to > show the issue. > > Compile it with a powerpc compiler built with -mcpu=power6 or power6x > > ~/gcc/install/gcc-test2/bin/gcc -O3 -S -o bad.s bad.c I can reproduce, thanks.
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #5 from seurer at gcc dot gnu.org --- Created attachment 42385 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42385&action=edit test case that shows the problem This is a cut down single function test case that shows the problem. I tried cutting out more but it changed how the code was generated too much to show the issue. Compile it with a powerpc compiler built with -mcpu=power6 or power6x ~/gcc/install/gcc-test2/bin/gcc -O3 -S -o bad.s bad.c And look for the srawi that shifts by 13. I changed it from 11 to make it easier to find because there are other shifts by 11. Then trace the result on its way to the function call. I see: 303:srawi 10,31,13 305:stw 10,29148(1) 325:ld 16,29144(1) 332:mr 27,16 545:mr 6,27 546:bl gl_write_texture_span
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 --- Comment #4 from seurer at gcc dot gnu.org --- extern void gl_write_texture_span( GLcontext *ctx, GLuint n, GLint x, GLint y, GLdepth z[], GLfloat s[], GLfloat t[], GLfloat u[], GLfloat lambda[], GLubyte red[], GLubyte green[], GLubyte blue[], GLubyte alpha[], GLenum primitive );
[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82569 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|other |middle-end Target Milestone|--- |8.0
