This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/66610] Aggregate assignment prevents store-motion
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 22 Jun 2015 10:58:49 +0000
- Subject: [Bug tree-optimization/66610] Aggregate assignment prevents store-motion
- Auto-submitted: auto-generated
- References: <bug-66610-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-06-22
CC| |rguenth at gcc dot gnu.org
Summary|Compound assignments |Aggregate assignment
|prevent value-numbering |prevents store-motion
|optimization with unions |
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
This isn't about value-numbering but about sinking the stores out of the loop
(so it becomes empty). For the field case it is loop store motion that
performs this conditional(!?) movement. For the non-field cases it determines
a dependence:
Memory reference 1: arr_5(D)->union_field.int_field
Unanalyzed memory reference 0: MEM[(struct s *)arr_5(D) + 4B].union_field =
arr_5(D)->union_field;
Querying dependencies of ref 1 in loop 1: dependent
because it doesn't handle aggregate assignments (simple_mem_ref_in_stmt
fails).
Confirmed.