This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PR middle-end/30191 (was: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug)


Andrew Pinski wrote:
> On Tue, 2006-12-12 at 21:16 +0100, Ulrich Weigand wrote:
> > Peter Bergner wrote:
> > 
> > >         * reload1.c (eliminate_regs_in_insn): Merge the plus_src "else" and
> > > 	the offset == 0 "then" clauses.
> > This part is OK.
> 
> This patch causes a build failure on spu-elf while compiling libstdc++.
> I will provide a reduced testcase tomorrow and some more information
> about the problem also.
> 
> It also causes a hppa bootstrap failure with Ada, see PR 30191.

Hmmm.  This is caused by strict checking of allowed immediate ranges
on various platforms.  On spu the failure can be circumvented by:

Index: gcc/config/spu/predicates.md
===================================================================
--- gcc/config/spu/predicates.md	(revision 119825)
+++ gcc/config/spu/predicates.md	(working copy)
@@ -57,6 +57,10 @@
   {
     if (spu_reg_operand (op, mode))
       return 1;
+    /* Accept any CONST_INT during reload, it will be fixed up later
+       to match constraints.  */
+    if (reload_in_progress && GET_CODE (op) == CONST_INT)
+      return 1;
     if (GET_CODE (op) == CONST_INT || GET_CODE (op) == CONST_VECTOR)
       return arith_immediate_p (op, mode, -0x200, 0x1ff);
     return 0;


On hppa, the strict check is here:

(define_predicate "arith_operand"
  (match_code "subreg,reg,const_int")
{
  return (register_operand (op, mode)
          || (GET_CODE (op) == CONST_INT && INT_14_BITS (op)));
})

On ia64, it's likely to be this one:

(define_predicate "gr_reg_or_22bit_operand"
  (ior (match_operand 0 "gr_register_operand")
       (and (match_code "const_int")
            (match_test "CONST_OK_FOR_J (INTVAL (op))"))))

On x86-64, it appears to be this test:

(define_predicate "x86_64_immediate_operand"
  (match_code "const_int,symbol_ref,label_ref,const")
{
  if (!TARGET_64BIT)
    return immediate_operand (op, mode);

  switch (GET_CODE (op))
    {
    case CONST_INT:
      /* CONST_DOUBLES never match, since HOST_BITS_PER_WIDE_INT is known
         to be at least 32 and this all acceptable constants are
         represented as CONST_INT.  */
      if (HOST_BITS_PER_WIDE_INT == 32)
        return 1;
      else
        {
          HOST_WIDE_INT val = trunc_int_for_mode (INTVAL (op), DImode);
          return trunc_int_for_mode (val, SImode) == val;
        }
      break;

While we could add reload_in_progress workarounds to all these, it does
look a bit unfortunate.  I hadn't thought so many platforms use these
types of checks in predicates ...

Peter, please revert your check-in for now so that the tree doesn't
stay in its broken state.  I'll try to come up with a less invasive
way to fix the powerpc problem.

Sorry for the breakage ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]