df.c and partial writes/REG_EQUAL notes

[Daniel Berlin]

On Tuesday, September 25, 2001, at 10:59  AM, Jan Hubicka wrote:

>>
>> Don't worry about the interactions, as the register allocator branch
>> A. has it's own version of df.c
>
> But once you will attempt to merge allocator in, you probably would not 
> want
> to have df1.c and df2.c right?
Yeah, but you shouldn't have to worry about the new-register allocator 
when working on the mainline. Currently, df.c on the new-regalloc branch 
and the mainline are in sync.
I do merges often enough to keep this true.  So if you break something, 
we'll just fix the allocator (assuming that's what is doing the wrong 
thing).

>
>> B. only uses df.c for reg defs and uses.  All dataflow is done without
>> df.c routines, because Michael doesn't want to use global liveness.
>
> As I've described, it misses one use at least, that should affect the 
> reg-alloc
> branch too.
>
> What exactly do you mean by global liveness?

> If you do some extra analyzis, you should make as much of the as 
> possible available
> to other passes - we already do have too many stuff doing analyzis 
> "just for myself"
Don't look at meef, I tried this argument on Michael, and it didn't work.
I don't like it either.
>>
>> I.E. It only cares about noticing all of the reg defs and uses, it
>> doesn't care whether df.c really knows what they do.
> My web code too..
Yeah.
Your web code must be pretty slow on large test cases, since my ebitmap 
patch *still* hasn't been reviewed.

>
> Honza