This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix alias grouping of name tags.
On 12/9/06, Daniel Berlin <firstname.lastname@example.org> wrote:
On 12/9/06, Eric Botcazou <email@example.com> wrote:
> > I'm not sure why you are asking for this comment. It sounds an awful
> > lot like you want me to write "This code actually works and does what
> > it is supposed to, regardless of what host you run it on", which seems
> > wrong. We generally document what we think isn't portable, not what
> > is portable.
> We document what is non obvious, and I think that the ultimate non-dependency
> on the host of this piece of code is non obvious.
I've already said why i disagree that it is non-obvious, and not to
belabor the pointer, but:
I think it's actually obvious to since it is just used for sorting a
list of pointers and removing duplicates.
And the code there already says
/* Replacing may aliases in name tags during grouping can end up with the
same SMT multiple times in the may_alias list. It's quicker to
just remove them post-hoc than it is to avoid them during
replacement. Thus, this routine sorts the may-alias list and
removes duplicates. */
qsort (VEC_address (tree, aliases), VEC_length (tree, aliases),
sizeof (tree), tree_pointer_compare);
If you think it needs more docs, please document it the way that you
feel makes more clear to the reader.
Again, i can't figure out what part of "sorting a list of trees
guaranteed to only have one pointer per UID (Something documented
elsewhere) based on pointer equality, and removing duplicates" you
think this is not clear, so i can't do this!
So please just document it how you feel is best so we can end this thread.
I quickly browsed through the code
and could not find any code that depends
on the order of items in var_ann_d::may_aliases.
However, not being familiar with available datastructures in gcc,
I have to ask if we have any other structure that's a pointer set
with no guarantee for the order (e.g. a hashtable of pointers)
- if so, we wouldn't have this (non-)issue in the first place,
since the order simply doesn't and shouldn't matter.
In fact, if the length of the may_aliases vector is even moderately large,
I can't imagine the linear search in various places would be acceptable.
(I guess your other changes keeping the may_alias set size
smaller would help quite a bit here).
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"