This is the mail archive of the 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]

Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX

Peter Bergner wrote:
On Thu, 2008-10-30 at 12:38 -0600, Jeff Law wrote:
Peter Bergner wrote:
Index: config/ia64/
--- config/ia64/   (revision 140417)
+++ config/ia64/   (working copy)
@@ -585,6 +585,6 @@ (define_predicate "ar_pfs_reg_operand"
 (define_predicate "basereg_operand"
   (match_operand 0 "register_operand")
-  return REG_P (op) && REG_POINTER (op);
+  return REG_P (op) && REG_POINTER (regno_reg_rtx[ORIGINAL_REGNO (op)]);

We shouldn't be hacking up backends to deal with this problem, it's entirely the wrong approach.

I have to agree with Jakub, why not? As Jakub mentioned, REG_POINTER cannot make sense on a hard register since it can contain many unrelated values, some being pointers and some not. We actually already hit and fixed a problem where we were setting the REG_POINTER attribute on a hard register:

Or are you saying this predicate should never be called with a
hard register?

It is valid on a hard register because after allocation hard registers aren't shared anymore. REG_POINTER must be passed through pseudos to hard registers or certain ports (PA) will fail miserably.

I'll repeat myself again, this is not something that should be fixed in the backend. These are problems in regrename and alias analysis and need to be fixed in those locations.


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