Kenneth Zadeck wrote:
I would be very careful to tread here. regstack is a can of worms and
not very good worms. We have had a lot of trouble retrofitting better
dataflow into regstack because of the fragile nature of it's
implementation.
Well, the approach so far has been 'don't touch cha
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> is it really necessary to do your pass after reg stack. Given that
>> there is no if conversion that runs after regstack what is your point?
>>
>>
> I am talking about cross-jumping after regstack.
>
>> I should point out that there are
Kenneth Zadeck wrote:
is it really necessary to do your pass after reg stack. Given that
there is no if conversion that runs after regstack what is your point?
I am talking about cross-jumping after regstack.
I should point out that there are no passes that currently use any
dataflow a
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>> Updating the LR dataflow when splitting a basic block is generally
>> pretty easy. You start from the end of the block and just interpret
>> the uses and defs
>> for each insn.
>>
>>
> This means duplicating this aspect of the propagate_block fun
Kenneth Zadeck wrote:
Updating the LR dataflow when splitting a basic block is generally
pretty easy.
You start from the end of the block and just interpret the uses and defs
for each insn.
This means duplicating this aspect of the propagate_block functionality.
If we really have to do thi
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> 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.
>>
>>
> if-conversion always joins blocks. But cross-jumping
Kenneth Zadeck wrote:
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.
if-conversion always joins blocks. But cross-jumping merges blocks or
partial blocks.
If the la
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
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 perf
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>> I suppose reg-live-at-start / reg-live-at-end information is
>>> actually easier
>>> to maintain during if-conversion that def-use chains.
>> This is true, certainly in theory, a lot less so in practice.
>> The way that you order things is thi
Kenneth Zadeck wrote:
I suppose reg-live-at-start / reg-live-at-end information is actually easier
to maintain during if-conversion that def-use chains.
This is true, certainly in theory, a lot less so in practice.
The way that you order things is this.
while (something changes and we
Joern Rennecke wrote:
> In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write:
>
>> depending on what you are doing, you can update the solution in place.
>> The point of the dataflow talk was not to say that you cannot do
>> anything incremental, it was to say that there are no good GEN
In http://gcc.gnu.org/ml/gcc/2006-07/msg00390.html, you write:
> depending on what you are doing, you can update the solution in place.
> The point of the dataflow talk was not to say that you cannot do
> anything incremental, it was to say that there are no good GENERAL
> techniques. Many times i
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> The right way to do this is not to build chains but to define your own
>> dataflow problem to do this.
>>
> But wouldn't I need to update the problem solution every time a change
> a bit of the
> program - which would be much more costly
Kenneth Zadeck wrote:
The right way to do this is not to build chains but to define your own
dataflow problem to do this.
But wouldn't I need to update the problem solution every time a change a
bit of the
program - which would be much more costly then doing a local update of some
local
Joern RENNECKE wrote:
> Kenneth Zadeck wrote:
>
>>
>>
>> you can have def-use chains, you can have use-def chains or you can have
>> both.
>> It seems like what you are asking for are use-def chains,
>>
> No, I want to know if there exists a path from the current *use* of a
> register to
> some o
Kenneth Zadeck wrote:
you can have def-use chains, you can have use-def chains or you can have
both.
It seems like what you are asking for are use-def chains,
No, I want to know if there exists a path from the current *use* of a
register to
some other *use* of the same register without goi
Joern RENNECKE wrote:
> I 've been looking at the problem of converting the struct-equiv code
> to use DEF-USE chains
> instead of global dataflow information, but I have hit a snag.
> We can find local registers as being registers that are defined
> somewhere in the examined (partial) block,
> and
I 've been looking at the problem of converting the struct-equiv code to
use DEF-USE chains
instead of global dataflow information, but I have hit a snag.
We can find local registers as being registers that are defined
somewhere in the examined (partial) block,
and have all their uses within the
19 matches
Mail list logo
