On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues is currently a
> structure.
The document is describing what the initial implementation will look
like. It will/should evolve as the implementation progresses.
> So you expect the ssa_operands to be associated via a hashtable
Hmm? No, they are there. Notice gimple_statement_with_ops and
gimple_statement_with_memory_ops.
> Concerning uids, it is always dificult to get some good data on this
> sort of thing. It seems to me that the UID would be handly and easy to
> bundle to some other integer, but it is not too important, especially if
> get some handy abstraction to map data with statements that we can
> easilly turn in between hashtables and arrays to see the difference
> instead of writting hasthables by hand in every pass doing this.
I grepped for uid and IIRC there are only two passes using UIDs: DSE and
PRE. We should see how they react to having uid taken away from them.
PRE is only using stmt_ann->uid as a convenient place to store the uid
for local dominance for purposes of Load PRE.
It's making up the UID on it's own :).
If there was stmt->aux we'd put it there instead (note that the
current way wastes memory, since we really only care about UID's for
statements that generate vdefs/vuses)
<while value numbering statements>
ann = stmt_ann (stmt);
ann->uid = stmt_uid++;
<in another function>
/* See if the vuse is defined by a statement that
comes before us in the block. Phi nodes are not
stores, so they do not count. */
if (TREE_CODE (def) != PHI_NODE
&& stmt_ann (def)->uid < stmt_ann (stmt)->uid)
{
