On 2/29/08 10:01 PM, Kenneth Zadeck wrote:
it is more productive to spend the cycles getting rid of the libcalls
rather than figuring out the edge cases. as steven implied, we have
been on the verge of getting rid of them for years and just have just
not fixed the last reason. The amount of time that we spent in 4.3
fixing the last two libcall bugs could have been much better spent just
ditching them.
I think both problems are orthogonal. One way of modeling libcalls
would be stringing all the insns in the libcall sequence with a single
DF object that's defined and used by all the insns in the sequence.
Sure, getting rid of libcalls will make things easier, but setting up
FUD chains on DF is needed for sparseness. In fact, what you describe
as birthpoints are almost exactly FUD chains. Implementing them over
the DF structures should not really be complicated at all:
- DF already has DEF and USE objects, these are similar to the memory
operands in GIMPLE.
- DF already links USE and DEF objects. It just does it in a simplistic
way, creating dense UD chains. All you have to do is factor them out at
dominance frontiers. The birthpoint idea is exactly the same as a PHI
node. A factoring device that lets you remove superfluous UD links.
subcall writes are not total kills and we are careful to model them
correctly when we see them individually. The question that i have is
when you see a join where one arm modifies the the first byte and the
other arm modifies the 4th byte. there is no store to the second and
third bytes and no way in rtl to exactly model it as a single move.
Two options:
- Conservatively treat partial references as full references. So, two
different subreg references with the same parent are considered
references to the parent. This is how we model references to arrays in
gimple. You will also need to model DEF-DEF links to avoid DCEing
partial stores.
- Create subreg objects in the DF data structure, similar to the SFTs in
gimple. Associate an object to each subreg. References to the subregs
are references to these SFTs and references to the parent register
create one reference per SFT in its children list.
I would go for option #2 as it models subregs separately. As opposed to
gimple, the list of SFTs per register will not be long.
Diego.
