This is the mail archive of the gcc@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: A plan for eliminating cc0 - Questions concerning the AVR target


BjÃrn Haase <bjoern.m.haase@web.de> writes:

> Imagine, you are having a clean md with a consistent "double set" 
> representation for all the patterns that actually alter the condition code. I 
> understood, that the problem for the optimization passes (e.g. combine) then 
> shows up only for instructions for which the second "set" actually happens to 
> be used. All of the other optimizations would not be detoriated by the second 
> "set".  IIUC combine would then also be able to simplify
> 
> (substract with cc set)  -- double set, but actually only a single set is used
> (compare with cc set)   -- single set, now problem)
> (read cc and branch)
> 
> to 
> 
> (substract with cc set)  
> (read cc and branch)
> 
> ? If this is true, I would not expect a serious deterioation of the 
> optimization, at least not for the AVR target.

I don't see how combine could perform that particular optimization.
It would try to substitute the subtract into the compare, and fail to
recognize the result.  Combine would not try to general parallel sets
and recognize that.  The CSE pass, on the other hand, might be able to
figure this out.  I'm not sure.

Note that combine was just an example of an optimization pass which
does not deal well with multiple sets.  Grep for single_set in the
compiler sources.

> Is there a way that makes it possible that only reload uses the patterns that 
> save and restore the condition code while everywhere else the usual patterns 
> are generated? In case of the AVR target, most of the time reload will be 
> able to use processor instructions that do not require the save/restore 
> operations (it could freely access addresses up to a constant offset of 64 
> from the stack pointer) and the costly operations would not show up very 
> frequently (only for large offsets).  

You could do it by writing your insn patterns as expanders which check
reload_in_progress || reload_completed and under those circumstances
emit insns which do not clobber the condition codes.

Ian


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