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]

Re: PATCH: Darwin specific 1-liners (1)



On Thursday, December 6, 2001, at 10:31 AM, David Edelsohn wrote:

>>>>>> Richard Henderson writes:
>
> Richard> This isn't the way preference works anymore.  The problem is 
> with ports
> Richard> that have different mnemonics -- particularly for move insns -- 
> and so
> Richard> really have to use different alternatives.  So now we look over 
> the set
> Richard> of alternatives and see if there's a superclass that contains 
> them, and
> Richard> if so, use that as a preference.
>
> Richard> I recommend "c,*l", since that will cause CTR to be preferred in 
> the
> Richard> register allocator, but reload will happily use LR if the value
> Richard> happens to already be there.
>
> 	I was trying to use LR -- even when the value was not already
> there -- if GCC decided that CTR was "too expensive".  That's the
> fundamental performance question that Dale hopefully can comment on: Do we
> *ALWAYS* want to use CTR unless the value happens to be in LR *OR* do we
> (strongly?) discourage use of LR.

I'd say the former.  That is what I was trying to do.  Can anybody offer a
case where it is a win to use LR?  In fact, I don't see what's wrong with
just "c".

(I hadn't noticed HARD_REGNO_RENAME_OK is undocumented.  It's obviously 
been
in there for a while, at least since April 2000.  I agree an undocumented 
macro
isn't a good thing to use.)

Sorry I didn't describe the problem earlier.  On Darwin the register 
allocator
picks CTR as you intended, but this is routinely remapped to LR by the 
regrename
phase.  This happens even for trivial cases like the following.  It happens
only with -fpic (the default).  Without -fpic, the instruction that feeds 
into
the tablejump is an add, not a mov, so the renamer leaves it alone.
I've enclosed some dump output below.  Does the same happen with AIX -fpic?

All the suggested changes fix the problem on Darwin.  Assuming there's a 
good
reason not to use just "c", I'll submit a patch for the "c,*l" variant 
unless
somebody has a better idea.

struct s { float x[3]; float f; int i; };
int foo (float y[3], float z[3], struct s* p)
{
     float d;
     int result;
     switch (p->i)
     {
       case 0: d = p->x[0]*z[0]; break;
       case 1: d = p->x[0]*y[0]; break;
       case 2: d = p->x[0]*z[0]; break;
       case 3: d = p->x[0]*y[0]; break;
       case 4: d = p->x[0]*z[0]; break;
       default: d = 0; break;
     }
     result = 0;
     if (d >= p->f) result = 1;
     return result;
}

 From ...23.flow2:
(insn 148 87 88 (set (reg:SI 66 ctr [140])
         (reg:SI 0 r0)) 310 {*movsi_internal1} (insn_list 87 (nil))
     (expr_list:REG_DEAD (reg:SI 0 r0)
         (nil)))

(jump_insn 88 148 89 (parallel[
             (set (pc)
                 (reg:SI 66 ctr [140]))
             (use (label_ref 89))
         ] ) 543 {*rs6000.md:13812} (insn_list 148 (nil))
     (expr_list:REG_DEAD (reg:SI 66 ctr [140])
         (nil)))

 From ...25.rnreg:   <all non-CTR/LR snipped>
Basic block 1:
Closing chain ctr at insn 88 (terminate_dead)
Register ctr (1): 148 [LINK_OR_CTR_REGS] 88 [LINK_OR_CTR_REGS]
Register ctr in insn 88, renamed as lr


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