[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures

[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


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

[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures

[mmitchel at gcc dot gnu dot org]

------- Comment #2 from mmitchel at gcc dot gnu dot org  2005-10-31 03:54 -------
Leaving as P2.

Do we know what's different?  The structure type is byte-aligned.  How did 2.95
justify using a 4-byte store?


-- 


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

[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2005-10-31 03:59 -------
(In reply to comment #2)
> Leaving as P2.
> Do we know what's different?
Yes in 4.0 and above there is no CONSTRUCTOR so we don't see the full
CONSTRUCTOR in expand so it could expand to just one integer store.

>The structure type is byte-aligned.  How did 2.95 justify using a 4-byte store?
There is no strict alignment requirements for either PPC or x86 which is why
GCC did it.


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2 Regression] Missing optimization when storing structures

[mmitchel at gcc dot gnu dot org]

------- Comment #4 from mmitchel at gcc dot gnu dot org  2006-02-24 00:25 -------
This issue will not be resolved in GCC 4.1.0; retargeted at GCC 4.1.1.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.1.1


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

[Bug middle-end/22141] [4.0/4.1/4.2 Regression] Missing optimization when storing structures

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2006-05-25 02:33 -------
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.1                       |4.1.2


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

------- Comment #6 from steven at gcc dot gnu dot org  2007-12-16 23:17 -------
Open regression with no activity since February 14.  Ping?


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2008-01-17 15:47 -------
Still broken (IMHO rightfully P2).

With 3.3 we get (x86_64):

f:
.LFB3:
        movl    $67305985, u(%rip)
        ret

while on trunk we have:

f:
.LFB2:
        movb    $1, u(%rip)
        movb    $2, u+1(%rip)
        movb    $3, u+2(%rip)
        movb    $4, u+3(%rip)
        ret

regardless of optimization flag (same for -Os and -O).  Gimplification now
produces

f ()
{
  u.a = 1;
  u.b = 2;
  u.c = 3;
  u.d = 4;
}

which makes the task of combining the initializer even harder.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2007-12-16 23:57:26         |2008-01-17 15:47:39
               date|                            |


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[dtemirbulatov at gmail dot com]

------- Comment #8 from dtemirbulatov at gmail dot com  2008-01-17 18:34 -------
This regression happens after the SSA was merged in to the mainline


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[pinskia at gmail dot com]

------- Comment #9 from pinskia at gmail dot com  2008-01-18 11:56 -------
Subject: Re:  [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing
structures

> ------- Comment #8 from dtemirbulatov at gmail dot com  2008-01-17 18:34 -------
> This regression happens after the SSA was merged in to the mainline

Yes because of the gimplifier ...

-- Pinski


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

------- Comment #10 from steven at gcc dot gnu dot org  2008-01-18 12:04 -------
Re. comment 7:

What does the initial RTL look like with GCC 3.3 and with a post tree-ssa
compiler?


-- 


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2008-01-18 12:08 -------
For 3.3-hammer I get (x86_64):

;; Function f

(note 2 0 3 NOTE_INSN_DELETED)

(note 3 2 4 NOTE_INSN_FUNCTION_BEG) 

(note 4 3 5 NOTE_INSN_DELETED)

(note 5 4 6 NOTE_INSN_DELETED)

(note 6 5 8 NOTE_INSN_DELETED)

(insn 8 6 9 (nil) (set (reg/v:SI 58 [ <anonymous> ])
        (const_int 0 [0x0])) -1 (nil)
    (nil))

(insn 9 8 10 (nil) (set (strict_low_part (subreg:QI (reg/v:SI 58 [ <anonymous>
]) 0))
        (const_int 1 [0x1])) -1 (nil)
    (nil))

(insn 10 9 11 (nil) (set (reg:DI 59)
        (const_int 2 [0x2])) -1 (nil)
    (expr_list:REG_EQUAL (const_int 2 [0x2])
        (nil)))

(insn 11 10 13 (nil) (set (zero_extract:DI (subreg:DI (reg/v:SI 58 [
<anonymous> ]) 0)
            (const_int 8 [0x8])
            (const_int 8 [0x8]))
        (reg:DI 59)) -1 (nil)
    (nil))

(insn 13 11 14 (nil) (parallel [
            (set (reg/v:SI 58 [ <anonymous> ])
                (and:SI (reg/v:SI 58 [ <anonymous> ])
                    (const_int -16711681 [0xffffffffff00ffff])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

(insn 14 13 16 (nil) (parallel [
            (set (reg/v:SI 58 [ <anonymous> ])
                (ior:SI (reg/v:SI 58 [ <anonymous> ])
                    (const_int 196608 [0x30000])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

(insn 16 14 17 (nil) (parallel [
            (set (reg/v:SI 58 [ <anonymous> ])
                (and:SI (reg/v:SI 58 [ <anonymous> ])
                    (const_int 16777215 [0xffffff])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

(insn 17 16 18 (nil) (parallel [
            (set (reg/v:SI 58 [ <anonymous> ])
                (ior:SI (reg/v:SI 58 [ <anonymous> ])
                    (const_int 67108864 [0x4000000])))
            (clobber (reg:CC 17 flags))
        ]) -1 (nil)
    (nil))

(insn 18 17 19 (nil) (set (mem/s:SI (symbol_ref:DI ("u")) [2 u+0 S4 A8])
        (reg/v:SI 58 [ <anonymous> ])) -1 (nil)
    (nil))

(note 19 18 21 NOTE_INSN_FUNCTION_END)

(code_label 21 19 0 1 "" [0 uses])


while on the trunk I see:


;; Function f (f)


;;
;; Full RTL generated for this function:
;;
(note 1 0 3 NOTE_INSN_DELETED)

;; Start of basic block ( 0) -> 2
;; Pred edge  ENTRY [100.0%]  (fallthru)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 2 3 4 2 NOTE_INSN_FUNCTION_BEG)
;; End of basic block 2 -> ( 3) 

;; Succ edge  3 [100.0%]  (fallthru)

;; Start of basic block ( 2) -> 3
;; Pred edge  2 [100.0%]  (fallthru)
(note 4 2 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)

(insn 5 4 6 3 t.c:12 (set (reg/f:DI 58)
        (symbol_ref:DI ("u") <var_decl 0x2b813a2b8460 u>)) -1 (nil))

(insn 6 5 7 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 58) [0 u.a+0 S1 A8])
        (const_int 1 [0x1])) -1 (nil))

(insn 7 6 8 3 t.c:12 (set (reg/f:DI 59)
        (const:DI (plus:DI (symbol_ref:DI ("u") <var_decl 0x2b813a2b8460 u>)
                (const_int 1 [0x1])))) -1 (nil))

(insn 8 7 9 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 59) [0 u.b+0 S1 A8])
        (const_int 2 [0x2])) -1 (nil))

(insn 9 8 10 3 t.c:12 (set (reg/f:DI 60)
        (const:DI (plus:DI (symbol_ref:DI ("u") <var_decl 0x2b813a2b8460 u>)
                (const_int 2 [0x2])))) -1 (nil))

(insn 10 9 11 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 60) [0 u.c+0 S1 A8])
        (const_int 3 [0x3])) -1 (nil))

(insn 11 10 12 3 t.c:12 (set (reg/f:DI 61)
        (const:DI (plus:DI (symbol_ref:DI ("u") <var_decl 0x2b813a2b8460 u>)
                (const_int 3 [0x3])))) -1 (nil))

(insn 12 11 17 3 t.c:12 (set (mem/s/c:QI (reg/f:DI 61) [0 u.d+0 S1 A8])
        (const_int 4 [0x4])) -1 (nil))
;; End of basic block 3 -> ( 4)

;; Succ edge  4 [100.0%]  (fallthru)

;; Start of basic block ( 3) -> 4
;; Pred edge  3 [100.0%]  (fallthru)
(note 17 12 14 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(jump_insn 14 17 15 4 t.c:13 (set (pc)
        (label_ref 16)) -1 (nil))
;; End of basic block 4 -> ( 6)

;; Succ edge  6 [100.0%] 

(barrier 15 14 13)

;; Start of basic block () -> 5
(code_label 13 15 18 5 1 "" [0 uses])

(note 18 13 16 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
;; End of basic block 5 -> ( 6) 

;; Succ edge  6 [100.0%]  (fallthru)

;; Start of basic block ( 4 5) -> 6
;; Pred edge  4 [100.0%]
;; Pred edge  5 [100.0%]  (fallthru)
(code_label 16 18 19 6 2 "" [1 uses])

(note 19 16 0 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
;; End of basic block 6 -> ( 1)

;; Succ edge  EXIT [100.0%]  (fallthru)


-- 


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

[Bug ada/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[steven at gcc dot gnu dot org]

------- Comment #12 from steven at gcc dot gnu dot org  2008-01-18 12:35 -------
So 3.3 expanded the initializer into sets of the individual components, but
with ANDs and ORs and a single MEM store, instead of MEM stores to the
individual components.

It seems to me that this is not something you'd want to fix with a tree
optimizer.  Maybe some local (i.e. per basic block) RTL pass:
1. Collect all stores
2. Find related stores
3. Combine related stores where possible and cheaper

I don't think this is not fixable for GCC 4.3.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |ada


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

[Bug middle-end/22141] [4.0/4.1/4.2/4.3 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2008-01-18 12:45 -------
Right.  You also need to watch for TBAA problems in the RTL you create.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|ada                         |middle-end


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[jsm28 at gcc dot gnu dot org]

------- Comment #14 from jsm28 at gcc dot gnu dot org  2008-07-04 16:54 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
                   |Missing optimization when   |Missing optimization when
                   |storing structures          |storing structures
   Target Milestone|4.1.3                       |4.2.5


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2008-11-19 21:12 -------
The advantage of such a RTL pass (or just adding such optimization to another
RTL pass) would be that it would handle also say:
struct S
{
  char a;
  char b;
  char c;
  char d;
} u __attribute__((aligned));

void
f1 (void)
{
  u = (struct S) { 1, 2, 3, 4 };
}

void
f2 (void)
{
  u.a = 1;
  u.b = 2;
  u.c = 3;
  u.d = 4;
}

void
f3 (void)
{
  u.d = 4;
  u.b = 2;
  u.a = 1;
  u.c = 3;
}

where only f1 used to be optimized into a single store by 3.2/3.3.  The
question is, do we want to do this only if constants are stored into
neighbouring < wordsize MEMs?  Do we need to use cselib to canonicalize the
addresses (similarly how DSE does it), or could we just rely on
MEM_EXPR/MEM_OFFSET/MEM_SIZE?  If bitfields are involved, combiner often helps
with merging adjacent bitfield stores into a single store, so this pass would
be desirable after the combiner (and probably before register allocation).


-- 


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2008-
                   |                            |11/msg01406.html
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-01-17 15:47:39         |2008-11-27 15:42:24
               date|                            |


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[bonzini at gnu dot org]

------- Comment #16 from bonzini at gnu dot org  2009-02-03 14:30 -------
*** Bug 37135 has been marked as a duplicate of this bug. ***


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |etienne_lorrain at yahoo dot
                   |                            |fr


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

[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures

[etienne_lorrain at yahoo dot fr]

------- Comment #17 from etienne_lorrain at yahoo dot fr  2009-02-03 16:38 -------
(In reply to comment #15)
> The advantage of such a RTL pass (or just adding such optimization to another
> RTL pass) would be that it would handle also say: ...

Why only limit that pass to constants, and only to writes:

etienne@cygne:~$ gcc --version
gcc (Debian 4.3.3-3) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

etienne@cygne:~$ cat tmp.c
struct S
{
  char a;
  char b;
  char c;
  char d;
} u, v;

void fct (void) {
  u.a = v.a;
  u.b = v.b;
  u.c = v.c;
  u.d = v.d;
}

etienne@cygne:~$ gcc -Os -S tmp.c -o tmp.s
etienne@cygne:~$ cat tmp.s
        .file   "tmp.c"
        .text
.globl fct
        .type   fct, @function
fct:
        movb    v, %al
        pushl   %ebp
        movl    %esp, %ebp
        popl    %ebp
        movb    %al, u
        movb    v+1, %al
        movb    %al, u+1
        movb    v+2, %al
        movb    %al, u+2
        movb    v+3, %al
        movb    %al, u+3
        ret
        .size   fct, .-fct
        .comm   u,4,4
        .comm   v,4,4
        .ident  "GCC: (Debian 4.3.3-3) 4.3.3"
        .section        .note.GNU-stack,"",@progbits
etienne@cygne:~$

 A single 32 bits read, and a single 32 bits write should be sufficient,
when none of the fields of the structure is declared volatile.


-- 


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

[Bug middle-end/22141] [4.3/4.4/4.5 Regression] Missing optimization when storing structures

[jsm28 at gcc dot gnu dot org]

------- Comment #18 from jsm28 at gcc dot gnu dot org  2009-03-31 18:49 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression]
                   |Missing optimization when   |Missing optimization when
                   |storing structures          |storing structures
   Target Milestone|4.2.5                       |4.3.4


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

[Bug middle-end/22141] [4.3/4.4/4.5 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2009-08-04 12:26 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug middle-end/22141] [4.3/4.4/4.5 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2010-01-03 13:30 -------
*** Bug 42594 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-gcc at firstfloor dot
                   |                            |org


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

[Bug middle-end/22141] [4.3/4.4/4.5/4.6 Regression] Missing optimization when storing structures

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-05-22 18:10 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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