Re: SMALL_REGISTER_CLASSES

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> No problem.  There's a lot of terminology we tend to use.  It takes a long
> time to learn all of them.  There's no way you could have known.
Thanks for the patience :)
> 
>   > 
>   > > This is not strictly a scheduler bug since no data dependency exists betw
>   > een
>   > 
>   > As I described, I believe scheduer ought to handle hard registers with
>   > SMALL_REGISTER_CLASSES as special case like many of other optimization does
> I don't think this should be the scheduler's responsibility.  If we are going
> to avoid such code motions, then parts of the compiler which compute data
> dependencies need to add a dependence between explicit uses of a register and
> uses via pseudos which can only be allocated to a single register.
huh. I agree, that much better is to remove S_R_C than fix it, but I still not
understand why scheduler behaviour is correct in S_R_C sense. Whats the exactly
definition of register lifetime? I interpret is as number of insns between first
and last use of register. In this sense rule "with S_R_C you can't extend hard register
lifetime" I interpret as "you can not put any new insns between two insns using hard
register". So I think scheduler is not alowed to put any insns between two 
insns using hard register so it is not dependent at register dependencies. Only
implementation I see is to make artificial basic block boundary there and
prohibit interblock scheduling...

Just curious...
>   > Sounds great. I tought that design decision is that reload will not spill
>   > hard register. So you mean that in future reload should do that?
> Yes.  Long term, I would like to see reload be able to handle these situations.
> 
> S_R_C is a hack.  It is a disgusting hack.  It is a disgusting hack to work
> around our lame register allocators & reloading pass.  It is a disgusting
> hack that needs to be eliminated rather than propagated.
100% agreed...
> 
> 
>   >  Or that
>   > LCM (or something else) will be able to move divmod outside the eax
>   > lifetime and solve this problem just by reordering code?
> No.  That's not the point of LCM.  LCM may hide some of these problems, but
> it would be by accident, not by design.  LCM is an algorithm to improve
> optimizations, not fix bugs.  Relying on it to hide these kinds of problems
> would be a mistake.
What I was thinking about is the sequence like this:
call_insn
<code>
(set (pseudo) (returned_hard_reg))

(this is situation where divmod pattern is in <code>)

if code clobbers returned_hard_reg (using constraints, not explicitly), even reload
working correctly with hard regs must spill it away hard_reg and then spill back
resulting in two unnecesary moves.  I think thats place for LCM :)

Honza
> 
> jeff

-- 
                       OK. Lets make a signature file.
+-------------------------------------------------------------------------+
|        Jan Hubicka (Jan Hubi\v{c}ka in TeX) hubicka@freesoft.cz         |
|         Czech free software foundation: http://www.freesoft.cz          |
|AA project - the new way for computer graphics - http://www.ta.jcu.cz/aa |
|  homepage: http://www.paru.cas.cz/~hubicka/, games koules, Xonix, fast  |
|  fractal zoomer XaoS, index of Czech GNU/Linux/UN*X documentation etc.  | 
+-------------------------------------------------------------------------+