[Bug rtl-optimization/47866] [4.5/4.6 Regression] gcc.dg/torture/vector-2.c fails on IA64

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-08 17:05:07 UTC ---
I think the bug here is during expansion.
We are expanding:
  vector(4) int t;
  vector(4) int t;
  vector(4) int a0;
  int D.2001;
  int D.2000;
  int D.1999;
  int D.1998;

<bb 2>:
  t = { 0, 0, 0, 0 };
  BIT_FIELD_REF <t, 32, 0> = 1;
  a0_18 = t;
  D.1998_3 = BIT_FIELD_REF <a0_18, 32, 0>;
  D.1999_4 = BIT_FIELD_REF <a0_18, 32, 32>;
  D.2000_5 = BIT_FIELD_REF <a0_18, 32, 64>;
  D.2001_6 = BIT_FIELD_REF <a0_18, 32, 96>;
  printf ("%d %d %d %d\n", D.1998_3, D.1999_4, D.2000_5, D.2001_6);
  t = { 0, 0, 0, 0 };
  BIT_FIELD_REF <t, 32, 32> = 1;
  a0_19 = t;
  D.1998_8 = BIT_FIELD_REF <a0_19, 32, 0>;
  D.1999_9 = BIT_FIELD_REF <a0_19, 32, 32>;
  D.2000_10 = BIT_FIELD_REF <a0_19, 32, 64>;
  D.2001_11 = BIT_FIELD_REF <a0_19, 32, 96>;
  printf ("%d %d %d %d\n", D.1998_8, D.1999_9, D.2000_10, D.2001_11);

All the memory references are MEM_SCALAR_P, except that the stores
BIT_FIELD_REF <t, 32, 0> = 1 and BIT_FIELD_REF <t, 32, 32> = 1 use
MEM_IN_STRUCT_P because store_field decides to override it (set_mem_attributes
doesn't override when it already has one or another one, but store_field does).
This, together with the fact that BIT_FIELD_REF <t, 32, 32> = 1 store
happens to use an address from post_modify and aliasing doesn't figure out it
is sfp based and what is the offset results in
fixed_scalar_and_varying_struct_p
returning true (where fixed scalar is e.g. the BIT_FIELD_REF <a0_19, 64, 0>
or BIT_FIELD_REF <a0_19, 64, 64> access from which BIT_FIELD_REF <a0_19, 32,
XX>
is derived, and "varying" "struct" is the BIT_FIELD_REF <t, 32, 32> = 1 store.
Thus sched1 reorders the reads after the store.

--- expr.c      (revision 170779)
+++ expr.c      (working copy)
@@ -5924,7 +5924,8 @@ store_field (rtx target, HOST_WIDE_INT b
       if (to_rtx == target)
        to_rtx = copy_rtx (to_rtx);

-      MEM_SET_IN_STRUCT_P (to_rtx, 1);
+      if (!MEM_SCALAR_P (to_rtx))
+       MEM_SET_IN_STRUCT_P (to_rtx, 1);
       if (!MEM_KEEP_ALIAS_SET_P (to_rtx) && MEM_ALIAS_SET (to_rtx) != 0)
        set_mem_alias_set (to_rtx, alias_set);

fixes this, though the generated code is still very much suboptimal (uses ld8.a
before the store (though, in the same insn group), thus I think it will always
find out that it changed and branch to a slow path doing the load again.