Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>> From that description I assumed that you really did care which uses
>> actually reached which other uses. The reaching uses problem tracks
>> each use separately. If this isn't what you need then you are free to
>> use LR which is certainly much cheaper than RU.
>>
>>
> Yes, LR is perfectly adequate. I was thinking in terms of def-use
> chains only
> because these can be kept more comprehensively up-to-date - i.e. when
> a register
> is live in a loop solely because it is used afterwards, and the use
> after the loop
> goes away, def-use chains won't keep a lingering livenes of the
> register in the
> loop.
> But since the exiting def-use chains don't actually fit the problem,
> there is no
> point in trying to use them here.
>
> So, in summary, the plan is:
> - Use LR (Live Registers) information for if-conversion / cross-jumping.
> - Update the information after each transformation to keep a correct,
> but not necessarily
> minimal solution.
> - After traversing the entire flowgraph, if anything changed,
> re-compute LR from scratch.
> - After re-computing LR, we need to traverse the flowgraph again.
> This might mean we
> end up doing more if-conversion / cross-jumping checks than with the
> current scheme, but
> since these checks are local, this should be generally cheaper than
> trying to keep a minimal
> LR solution all the time.
>
> I'm not sure how to best handle splitting blocks when doing
> cross-jumping.
> propagate_block can produce inconsistant liveness information for
> stack regs after
> reg_stack. Currently this is handled by zeroing out all the stack reg
> liveness information.
> Maybe we shouldn't even try to update LR for the split upper parts of
> the original BBs.
> The live-at-end information for the joined lower part should be
> bassically the same as both
> blocks original BBs had, and doing further optimizations with a
> partial or fully joined block
> appears not unlikely; however, the remaining unjoined upper parts of
> the original BBs
> are somehow differentfrom each other, so any further cross-jumping for
> them, while not
> impossible, seems unlikely - AFAICT it would require a complete
> corss-jumping of the joined
> lower part with some other block. So maybe we could mark them has
> having no valid LR
> information, and not consider them again till the next global LR
> recomputation.
You should do this starting from the dataflow branch. The version of
if-cvt there works as I have mentioned in the previous mail and does not
use propagate block at all.
