[Bug middle-end/35292] New: Missing Const Prop -- union fields

[Bug middle-end/35292] New: Missing Const Prop -- union fields

[xinliangli at gmail dot com]

union U {
  struct C
   {
      char c[4];
   }cc;

   int ii;
} u ;

int foo(int i)
{
   u.ii  = 20;

   return u.cc.c[0] + u.cc.c[1];  // Const prop target -- not performed
}


-- 
           Summary: Missing Const Prop -- union fields
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: xinliangli at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug middle-end/35292] Missing Const Prop -- union fields

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-22 10:46 -------
This is related to PR34043 and will be fixed by tweaking SCCVN and the
introduction of MEM_REF.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-02-22 10:46:25
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug middle-end/35292] Missing Const Prop -- union fields

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-23 05:50 -------
More than just constant prop, see PR 25972 for more info on what else it can be
done with union in the same way.

Actually I think MEM_REF will make it worse and will not help.  In fact I still
think MEM_REF is a bad idea and will cause worse aliasing issues with unions
than that are already done.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|                            |missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug middle-end/35292] Missing Const Prop -- union fields

[rguenther at suse dot de]

------- Comment #3 from rguenther at suse dot de  2008-02-24 21:14 -------
Subject: Re:  Missing Const Prop -- union fields

On Sat, 23 Feb 2008, pinskia at gcc dot gnu dot org wrote:

> ------- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-23 05:50 -------
> More than just constant prop, see PR 25972 for more info on what else it can be
> done with union in the same way.
> 
> Actually I think MEM_REF will make it worse and will not help.  In fact I still
> think MEM_REF is a bad idea and will cause worse aliasing issues with unions
> than that are already done.

Please elaborate.  This handwaving doesn't help.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug tree-optimization/35292] Missing Const Prop -- union fields

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-01 21:48 -------
RTL DSE does this optimization ...

(insn 8 7 11 2 t.c:12 (set (mem/s/c:SI (reg/f:SI 60) [0 u.ii+0 S4 A32])
        (const_int 20 [0x14])) 47 {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 60)
        (nil)))

(insn 11 8 14 2 t.c:12 (set (reg:SI 63 [ u.cc.c+1 ])
        (sign_extend:SI (mem/s/j:QI (plus:SI (reg/f:SI 60)
                    (const_int 1 [0x1])) [0 u.cc.c+1 S1 A8]))) 132
{extendqisi2} (expr_list:REG_DEAD (reg/f:SI 62)
        (nil)))

(insn 14 11 15 2 t.c:12 (set (reg:SI 65 [ u.cc.c ])
        (sign_extend:SI (mem/s/j:QI (reg/f:SI 60) [0 u.cc.c+0 S1 A32]))) 132
{extendqisi2} (expr_list:REG_DEAD (reg/f:SI 64)
        (nil)))

Into:

(insn 30 7 31 2 t.c:12 (set (reg:QI 66)
        (const_int 0 [0x0])) -1 (nil))

(insn 31 30 8 2 t.c:12 (set (reg:QI 67)
        (const_int 20 [0x14])) -1 (nil))

(insn 8 31 11 2 t.c:12 (set (mem/s/c:SI (reg/f:SI 60) [0 u.ii+0 S4 A32])
        (const_int 20 [0x14])) 47 {*movsi_1} (nil))

(insn 11 8 14 2 t.c:12 (set (reg:SI 63 [ u.cc.c+1 ])
        (sign_extend:SI (reg:QI 66))) 132 {extendqisi2} (nil))

(insn 14 11 15 2 t.c:12 (set (reg:SI 65 [ u.cc.c ])
        (sign_extend:SI (reg:QI 67))) 132 {extendqisi2} (expr_list:REG_DEAD
(reg/f:SI 60)
        (nil)))

And then combine simplifies it into just return 20 with the memory store still


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization
           Keywords|                            |TREE
   Last reconfirmed|2008-02-22 10:46:25         |2009-01-01 21:48:16
               date|                            |
            Version|unknown                     |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug tree-optimization/35292] Missing Const Prop -- union fields

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-05-23 09:23 -------
Hm, with my fix for PR36327 there is now a natural place to do this in SCCVN.
The question is how to properly get to the desired value.  We have (bit
access ranges):

 c.[0..31] = 20;

 ... = c.[0..7];
 ... = c.[8..15];

(or others depending on byte-order).  Ideally we can translate this by
using a BIT_FIELD_REF on the value stored - at least if both stored value
and read value are integral types.  For other type mixes proper
VIEW_CONVERT_EXPRs need to be done.  The question is if it is worth it
for non-constants.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

[Bug tree-optimization/35292] Missing Const Prop -- union fields

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.7.0
         Resolution|                            |FIXED
   Target Milestone|---                         |4.7.0
      Known to fail|                            |4.6.4

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-05 14:05:00 UTC ---
This is fixed in 4.7, done by FRE1:

Replaced u.cc.c[0] with 20 in D.1722_1 = u.cc.c[0];
Replaced (int) D.1722_1 with 20 in D.1723_2 = (int) D.1722_1;
Replaced u.cc.c[1] with 0 in D.1724_3 = u.cc.c[1];
Replaced (int) D.1724_3 with 0 in D.1725_4 = (int) D.1724_3;
Replaced D.1723_2 + D.1725_4 with 20 in D.1721_5 = D.1723_2 + D.1725_4;
foo (int i)
{
  int D.1725;
  char D.1724;
  int D.1723;
  char D.1722;
  int D.1721;

<bb 2>:
  u.ii = 20;
  D.1722_1 = 20;
  D.1723_2 = 20;
  D.1724_3 = 0;
  D.1725_4 = 0;
  D.1721_5 = 20;
  return D.1721_5;
}