Re: Tree-SSA self checking infrastructure

[law at redhat dot com]

In message <1069268637.30703.858.camel@p4>, Andrew MacLeod writes:
 >> Yes.  Though it'd be nice to be able to check this independently of doing
 >> SSA->Normal.
 >> 
 >> In fact, if you had that capability and put the check immediately after PRE
 >,
 >> you'd find it failing as PRE is creating uses which are not dominated by
 >> defs.
 >> 
 >
 >I could try hacking together the few bits into one function and see if
 >it works... should be pretty simple.
If you need a testcase, look for a message from me in the archives
"More PRE problems".  PRE will create a use which is not dominated by the 
def for the included testcase.

 >Well, its all pretty modular. Im not sure what the resulting speed with
 >be. It requires building the live-on-entry information for the SSA_NAMES
 >in question, then live on exit, then building a conflict graph,
 >coalescing them, running the SSA->Normal copy algorithm, inserting
 >required copies, then rewriting back to the original variable.
Well, there's one way to find out :-)  It can't be that much worse
than the contortions I'm going through to build a good jump threader.


 >What I would need to have for input would be a list of all the base
 >variables you want to un-ssa-ify. If you have a complete list of the
 >SSA_VERSIONs already, that would prevent a pass through the IL looking
 >for them.
Ah, yes, I've got the base variables handy in sbitmap form :-)  I'll 
translate into whatever form you might want :-)

It probably wouldn't be that terrible to get the SSA_NAMEs.  That data
is pretty handy at the time when I realize that I'm going to need to
re-rewrite something.

 >Before the algorithm can run, they have to be collected and
 >enumerated in a partition data structure (var_map).  Thats pretty
 >trivial to set up if you know what they are. 
 >tree-ssa-live.c::create_ssa_var_map() builds the var_map by traversing
 >the entire function once looking for uses and defs and registering them
 >via a call to tree-ssa-live.c::register_ssa_partition(). Everything is
 >then driven from that partition list. You'd want to create one with the
 >SSA_NAMEs you care about rewriting back. 
 >
 >After that, its just a matter of calling the appropriate routines, and
 >tweaking the rewrite-IL step a hair.  I'll write an entry point which
 >takes in a var_map and rewites back to the original variables.
Sweet.  If you can set up that entry point and throw the code my way, I'll
take it from there and see what's missing/broken ;-)
jeff