[Bug target/53647] [4.8 Regression] gcc.c-torture/compile/20011229-1.c and gcc.c-torture/compile/pr25311.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Uros Bizjak <ubizjak at gmail dot com> 2012-06-12 19:45:56 UTC ---
Alternative patch with the same functionality:

--cut here--
Index: tree-ssa-phiopt.c
===================================================================
--- tree-ssa-phiopt.c   (revision 188475)
+++ tree-ssa-phiopt.c   (working copy)
@@ -1976,12 +1976,14 @@
 /* Determine whether we should attempt to hoist adjacent loads out of
    diamond patterns in pass_phiopt.  Always hoist loads if
    -fhoist-adjacent-loads is specified and the target machine has
-   a conditional move instruction.  */
+   defined cache line size and a conditional move instruction.  */

 static bool
 gate_hoist_loads (void)
 {
-  return (flag_hoist_adjacent_loads == 1 && HAVE_conditional_move);
+  return (flag_hoist_adjacent_loads == 1
+         && PARAM_VALUE (PARAM_L1_CACHE_LINE_SIZE)
+         && HAVE_conditional_move);
 }

 /* Always do these optimizations if we have SSA
--cut here--

--- Comment #9 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2012-06-12 19:46:30 UTC ---
Yes, that can be done, but the question is whether it is correct, or just
hiding the issue.  Do the processors really not have cache?  Or was this just
an error not filling in the values?  I don't want to hide a real problem if
that's the situation.  Waiting for someone to clarify the intent behind these
processor descriptions.

There's nothing in the documentation of the parameter to suggest zero is a
magic number for no cache, but nothing to suggest otherwise, either.