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: Reload problem

> I think the code in push_reload is primarily at fault here.  This is an
> optimization trying to reduce the number of spill registers, but it is
> very tricky to get right.  We've already had a number of problems with
> this code before, and it has a growing list of conditions that must be
> met before we use it.

Yes, the code is already barely understandable. But at least, up to now, all 
conditions appear to be verifiable a priori.

> I think someone (maybe Joern?) once proposed modifying this code to emit
> a test reload and try to recognize it.  If this fails, then we can't use
> the dying register as the spill register.  This would mean doing some of
> the stuff gen_reload does, e.g. call emit_insn, recog_memoized,
> extract_insn, and constrain_operands.  And only if all of these succeed
> is it safe to use the dying register as the spill register.
> It seems like we shouldn't have to do all of that work, but I don't see
> any other way to fix it in push_reload.

It is my understanding that recognizing insns is an expensive process, so I 
think that adding it to push_reload would be the last resort solution.

But, more fundamentally, I think that we abuse push_reload by calling it on

(plus:SI (reg:SI 1 r1 [174])
         (const_int 128 [0x80]))

because we implicitly ask it to do two reloads in a row, while it is only  
wired to do one. So it implicitly relies on gen_reload to do the second one, 
but this is IMHO more a hack than a feature.

> Fixing find_reloads_address_part sounds reasonable also.  However, the
> only way to see if the PLUS operands are valid is to do the same thing I
> mentioned above, e.g. emit an instruction and see if it can be
> recognized and if the operands match the constraints.  Since we have
> less info here (i.e. we don't have the reload register which is the
> destination register for the insn), this is less likely to be completely
> safe.

I think that fixing find_reloads_address_part would be the cleanest solution 
and, again, that an a priori solution would be better than the recog stuff.

Could we extend the scope of the LEGITIMATE_CONSTANT_P macro, by adding a 
second argument PLUS_CLASS that would be specified as follows:
- if PLUS_CLASS == NO_REGS, returns 1 if the constant is valid as an 
immediate operand in a SET,
- if PLUS_CLASS != NO_REGS, returns 1 if the constant is valid as an 
immediate operand in a PLUS with a register of class PLUS_CLASS?

All calls to find_reloads_address_part are performed either on a constant or 
on a PLUS with a base hard reg and a constant so we could add a new 
parameter PLUS_CLASS to the function.

Thanks for your help in clearing up this problem.

Eric Botcazou

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