[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register

["vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317

--- Comment #21 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #17)
> Thanks Vlad, that patch helped.  Prior to your patch we had 15 reloads of
> the PIC register from memory, after your patch we have just 9.   However,
> several of the remaining 9 seem to be redundant.
> 
> LRA never considers a block starting with a label as participating in an
> EBB.  That's overly conservative.  A block can participate in an EBB if all
> of its predecessors are part of the same EBB.
> 
> That's particularly useful in CFGs like
>  
>     A
>    /|
>   / |
>  B  |
>   \ |
>    \|
>     C
> 
> [ Flow downward of course. ]
> 
> 
> If we assume that B is the fallthru path, then LRA will try to make AB into
> an EBB.  But it will not consider C because C will start with a label.  That
> ultimately causes missed inheritances in this example.

I am agree the bigger scope would help but it is hard to implement.  If we
consider the graph hammock structure, inherited value of pseudo P in A to C
might be changed in B.  It works if we don't change it in B but then the
structure can be dependent on considered pseudos for inheritance.  It is harder
to update live info too and to undo inheritance transformations if they fail.

The biggest problem with PIC pseudo is in that it can not treated as the rest
of pseudos with live range splitting perspective because of possible creation
of memory with pic pseudo value.  It is hard to decide what pseudo (or hard
register) to use for such memory in a particular place as it can be in
different pseudos (hard registers) if we permit usual pseudo live range
splitting for pic pseudo.