* On VIEW_CONVERT_EXPRs and TBAA
@ 2009-09-24 10:53 Richard Guenther
2009-09-26 20:41 ` Eric Botcazou
0 siblings, 1 reply; 4+ messages in thread
From: Richard Guenther @ 2009-09-24 10:53 UTC (permalink / raw)
To: gcc
While looking at PR38747 again I was diving into the alias.c code
and tried to confirm that it does what I think it does for
VIEW_CONVERT_EXPR. And in fact it basically does.
In general there are odds between what get_alias_set does if you
pass it a reference tree compared to what it does if you pass it
a type. In particular whether it returns the alias-set of the
innermost or the outermost aliased component is not really consistent.
But - onto that VIEW_CONVERT_EXPR. VIEW_CONVERT_EXPR is basically
ignored / skipped, which means that if you have C++ code that does
*(type2 *)&X and translate it to VIEW_CONVERT_EXPR <type2> (X) then
you have generated wrong code (this is PR38747, forwprop does that).
With VIEW_CONVERT_EXPR you can also easily create the situation
where for a reference tree, let it be VIEW_CONVERT_EXPR <T2> (X.a).b
like commonly seen in Ada, the alias-set of the outermost component
is not a subset of that of the innermost one (the relationship that
is usually assured to be true by the record_component_aliases
machinery). You are probably safe here if only your frontend generates
such conversions and it is very consistent on how it balances
V_C_Es with accesses through pointers (because in the above case
if .b is an addressable component an access via a pointer to type
of b wouldn't necessarily alias the cited reference tree).
The alias-oracle tries to use both the outermost and innermost
alias-sets for disambiguations, but relies on the outermost alias-set
being a subset of the innermost one - a relationship that V_C_E can
break.
So, what I'd like to know is in which circumstances the Ada
frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
applies to ensure consistent TBAA.
Thanks,
Richard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: On VIEW_CONVERT_EXPRs and TBAA
2009-09-24 10:53 On VIEW_CONVERT_EXPRs and TBAA Richard Guenther
@ 2009-09-26 20:41 ` Eric Botcazou
2009-09-26 22:24 ` Richard Guenther
0 siblings, 1 reply; 4+ messages in thread
From: Eric Botcazou @ 2009-09-26 20:41 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
> With VIEW_CONVERT_EXPR you can also easily create the situation
> where for a reference tree, let it be VIEW_CONVERT_EXPR <T2> (X.a).b
> like commonly seen in Ada, the alias-set of the outermost component
> is not a subset of that of the innermost one (the relationship that
> is usually assured to be true by the record_component_aliases
> machinery). You are probably safe here if only your frontend generates
> such conversions and it is very consistent on how it balances
> V_C_Es with accesses through pointers (because in the above case
> if .b is an addressable component an access via a pointer to type
> of b wouldn't necessarily alias the cited reference tree).
I presume you're talking exclusively about the addressable case here, because
in Ada the alias set of (the type of) the outermost component is not a subset
of (that of) the innermost one by default (at least for scalar types, it is
for aggregate types because of implementation limitations), there being a VCE
or not; the field must explicitly be declared addressable.
> So, what I'd like to know is in which circumstances the Ada
> frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
> applies to ensure consistent TBAA.
The Ada compiler generates a lot of VIEW_CONVERT_EXPRs for conversions between
aggregate (sub)types because it generates a lot of aggregate subtypes from a
given aggregate type. These conversions are purely formal and their purpose
is to ensure type consistency. The Ada compiler also uses VIEW_CONVERT_EXPR
to implement up-casting
type Base is tagged record
I : Integer;
end record;
type Derived is new Base with record
J : Integer;
end record;
D : Derived;
Base (D).I
is translated into VIEW_CONVERT_EXPR<base>(d).i (a questionable use of VCE, no
doubt about that). There are a few other, more obscur uses, but we get rid
of the most controversial one (optimization barrier on scalars for VRP).
The main countermeasure to ensure consistent TBAA is decl.c:relate_alias_sets
which is aimed at doing the right thing when types are VCEd to each other.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: On VIEW_CONVERT_EXPRs and TBAA
2009-09-26 20:41 ` Eric Botcazou
@ 2009-09-26 22:24 ` Richard Guenther
2009-09-27 9:40 ` Eric Botcazou
0 siblings, 1 reply; 4+ messages in thread
From: Richard Guenther @ 2009-09-26 22:24 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc
On Sat, 26 Sep 2009, Eric Botcazou wrote:
> > With VIEW_CONVERT_EXPR you can also easily create the situation
> > where for a reference tree, let it be VIEW_CONVERT_EXPR <T2> (X.a).b
> > like commonly seen in Ada, the alias-set of the outermost component
> > is not a subset of that of the innermost one (the relationship that
> > is usually assured to be true by the record_component_aliases
> > machinery). You are probably safe here if only your frontend generates
> > such conversions and it is very consistent on how it balances
> > V_C_Es with accesses through pointers (because in the above case
> > if .b is an addressable component an access via a pointer to type
> > of b wouldn't necessarily alias the cited reference tree).
>
> I presume you're talking exclusively about the addressable case here, because
> in Ada the alias set of (the type of) the outermost component is not a subset
> of (that of) the innermost one by default (at least for scalar types, it is
> for aggregate types because of implementation limitations), there being a VCE
> or not; the field must explicitly be declared addressable.
Yes, addressable in the way that get_alias_set would not skip the
component as component_uses_parent_alias_set.
> > So, what I'd like to know is in which circumstances the Ada
> > frontend uses VIEW_CONVERT_EXPRs and what counter-measures it
> > applies to ensure consistent TBAA.
>
> The Ada compiler generates a lot of VIEW_CONVERT_EXPRs for conversions between
> aggregate (sub)types because it generates a lot of aggregate subtypes from a
> given aggregate type. These conversions are purely formal and their purpose
> is to ensure type consistency. The Ada compiler also uses VIEW_CONVERT_EXPR
> to implement up-casting
>
> type Base is tagged record
> I : Integer;
> end record;
>
> type Derived is new Base with record
> J : Integer;
> end record;
>
> D : Derived;
> Base (D).I
>
> is translated into VIEW_CONVERT_EXPR<base>(d).i (a questionable use of VCE, no
> doubt about that).
C++ for this case has a FIELD_DECL in Derived of type Base, so the
middle-end sees d.<anonymous>.i here (and thus also automatically
gets the TBAA hierarchy correct by means of recording component aliases).
The Ada way doesn't look too obscure to me.
> There are a few other, more obscur uses, but we get rid
> of the most controversial one (optimization barrier on scalars for VRP).
>
> The main countermeasure to ensure consistent TBAA is decl.c:relate_alias_sets
> which is aimed at doing the right thing when types are VCEd to each other.
Ok, thanks.
Richard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: On VIEW_CONVERT_EXPRs and TBAA
2009-09-26 22:24 ` Richard Guenther
@ 2009-09-27 9:40 ` Eric Botcazou
0 siblings, 0 replies; 4+ messages in thread
From: Eric Botcazou @ 2009-09-27 9:40 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
> C++ for this case has a FIELD_DECL in Derived of type Base, so the
> middle-end sees d.<anonymous>.i here (and thus also automatically
> gets the TBAA hierarchy correct by means of recording component aliases).
Ada has a _Parent FIELD_DECL in Derived (of type a subtype of Base) so it
should be able to do d._Parent.i and this would be a lot nicer IMO.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-09-27 6:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-24 10:53 On VIEW_CONVERT_EXPRs and TBAA Richard Guenther
2009-09-26 20:41 ` Eric Botcazou
2009-09-26 22:24 ` Richard Guenther
2009-09-27 9:40 ` Eric Botcazou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).