Re: GIMPLE tuples document uploaded to wiki

[Jan Hubicka <jh at suse dot cz>]

> 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.

Uh, I've somehow mised (looking for ssa-operands pattern, not for the
unwound structure)
> 
> 
> > 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.

This is because we now put the data into annotations themselves or use the aux
pointer.
I am not quite sure how to easilly grep for aux use of stmt annotations,
loop-im definitly does that.  Also addresses_taken and value_handles can
be probably made separate arrays, since they deifnitly don't need to
live at IPA level.

Honza
> 
> 
> > I have some data for this, lets discuss it at ICE.
> 
> Sounds good.