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: Ada and TBAA and arrays vs. VIEW_CONVERT_EXPRs


On Sun, 8 Feb 2009, Richard Guenther wrote:

> On Sun, 8 Feb 2009, Eric Botcazou wrote:
> 
> > > The problem is that the gimplifier through gimplify_init_constructor
> > > happily generates "aliases" for { 32, 50, 53, 53 } to produce a
> > > temporary, but at the same time accesses the result in whole.  Which
> > > of course won't work if the element and the array object have
> > > non-conflicting alias sets.  Huh.  No idea how to fix that.
> > 
> > Do you mean that A[i] and A cannot be disambiguated without TBAA anymore?  Or 
> > does the problem pertain only to the VIEW_CONVERT_EXPR around A?
> 
> Yes, A[i] and A are not disambiguated without TBAA unless the frontend
> explicitly allows this.  Citing from get_alias_set:
> 
>   /* Unless the language specifies otherwise, treat array types the
>      same as their components.  This avoids the asymmetry we get
>      through recording the components.  Consider accessing a
>      character(kind=1) through a reference to a character(kind=1)[1:1].
>      Or consider if we want to assign integer(kind=4)[0:D.1387] and
>      integer(kind=4)[4] the same alias set or not.
>      Just be pragmatic here and make sure the array and its element
>      type get the same alias set assigned.  */
>   else if (TREE_CODE (t) == ARRAY_TYPE
>            && !TYPE_NONALIASED_COMPONENT (t))
>     set = get_alias_set (TREE_TYPE (t));
> 
> the problems with other languages were simply too big.  The gimplifier
> problem hints into the same direction here.  Thus, the above means
> that if it is legal to take the address of an element both the
> array and the element will share their alias sets (which is always
> for any language but Ada and Java).

To expand a little - passes like IVOPTs, the vectorizer and others
happily create pointers to array elements without making sure the
correct alias set is used for dereferences of these pointers
(so they expect that the element type alias set is at least a subset
of the array alias set).  Fixing this up will be an interesting task ;)
Thus, I think that all languages setting TYPE_NONALIASED_COMPONENT or
DECL_NONADDRESSABLE_P are playing russian roulette.

Richard.


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