This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] VEC and tree aliasing


On Fri, 2005-04-22 at 09:01 +0100, Nathan Sidwell wrote:
> This patch reworks the field offset VEC creation in tree alias handling.
> 
> The primary goal is to use a vector of objects, rather than a vector of
> pointers

> .  Whilst there I became somewhat confused by the funky loop
> peeling in push_fields_onto_fieldstack.  There's no guarantee that the
> first member of a type's DECL_FIELDS list will be a FIELD_DECL,
But if it isn't, it will continue on to the next one, as it should.

!       if (TREE_CODE (field) != FIELD_DECL)
> ! 	continue;

>  and why
> should the first one be handled specially anyway?

The push_fields code originally came from the struct alias analyzer,
which needed to handle the first specially  because the first field had
to "overwrite" the information we had created for the "whole
variable" (IE before we saw that it had fields).  
I've never pretended that code didn't need to be rewritten, and in fact,
it's been on my list to do so (I'm pretty sure i've mentioned it a few
times).

>   AFAICT the only
> difference in the handling of the first one, and the handling of the
> remainder is the non-addition of 'bitpos_of_field (field)' to the
> recursive call (but not the direct push)
>   That looks like a noop to me,
> because the first encountered field would be expected to have an offset
> of zero anyway 

It was done to handle some very weird code (it was either C++ or Ada. I
wish i could remember) i came across where the first field encountered
actually did not have an offset of 0, and it actually caused us to give
the field the wrong offset, causing an aliasing bug later on.

> (unless some FE makes funky structures -- in which case
> it would be a _bug_).
> 

I was as surprised as you were, but i assumed it was valid in one of the
languages we support, so i just went with it :)

Also, I have never seen anything documented that restricts us to such a
limitation.

If you want to make such a restriction, it would mean i could go back to
field numbering in the struct aliaser, which would buy us a little
speed.

Try bootstrapping with Ada on just to make sure you aren't breaking
anything, but it's otherwise fine by me ;)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]