> > tree_int_cst_equal will return false if offsets are not INTEGER_CST.
> > I was not sure if I can safely use operand_equal_p. What happens for
> > fields with variable offsets when I inline two copies of same function
> > which takes size as parameter and make the size different? Will I get
> > here proper SSA name so operand_equal_p will work?
>
> No, you get a DECL, but yes, I think operand_equal_p will work.
> Consider two _same_ variable sizes, you'll not see that you
> have to return zero then? But yes, in case you have types
> globbed to the canonical type (but not FIELD_DECLs) then
> you'll get false !operand_equal_p as well.
>
> The question is really what is desired here. If you want/need precision
> for non-constant offsets then you have to look at the COMPONENT_REF
> trees because the relevant offset (SSA name) is only there
> (in TREE_OPERAND (component_ref, 2)).
>
> If you want to give up for non-constants and can do that without
> correctness issue then fine (but Ada probably would like to have
> it - so also never forget to include Ada in testing here ;))
I would like to have precision here. so perhaps as incremental change I
can
1) reorganize callers to pass refs rather than just field_decls
2) check if TREE_OPERAND (component_ref, 2) is non-NULL in both case
a) if so do operand_equal_p on them and return 0 on match
b) if there is no match see if I have same canonical types and
return 1 then
c) return -1 otherwise
3) continue with parsing FIELD_DECLS we work on now.
>
> Oh, OK ... a bit more explaining commentary might be nice
> (at the top of the function - basically what the input
> constraints to the FIELD_DECLs are).
OK, will try to improve comments (though i tried to be relatively
thorough).
Honza
>
> Btw, the offsets in FIELD_DECLs are relative to DECL_CONTEXT so
> comparing when DECL_CONTEXT are not related at all doesn't make
> any sense. Well, unless we know _those_ are at the same offset,
> so - the constraint for the FIELD_DECLs we compare is that
> the containing structure type object instances live at the same
> address?
>
> Richard.
