Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 04/05/17 15:28, Jakub Jelinek wrote:
> On Wed, Apr 05, 2017 at 09:46:09AM +0000, Bernd Edlinger wrote:
>> this is related to the P1 codegen bug PR79671:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>>
>> Therefore I would like to add this now although
>> the trunk is already at in stage 4.
>>
>> I propose to add a new type attribute always_alias that
>> works like may_alias but unlike may_alias it should
>> also make instances alias anything.  It is also exposed
>> in C/C++ as __attribute__((always_alias)).
>
> I have just two small comments, for review IMHO want agreement
> between Jason and Richard on this.
>
> One thing is whether it is a good idea to keep this info in the IL
> as an attribute, especially when you add it automatically in the
> C++ FE.  I see e.g. 25 spare bits in tree_type_common.  Don't say we
> need to waste them, but I'd say in C++ unsigned char arrays are fairly
> common and thus not having to create the attribute for them each time
> and look it up might be beneficial.
>

Yes, but it is not clear if it will be available in LTO, for instance
we used to stream TYPE_ALIAS_SET == 0 information to let frontends mark
types that are opaque for TBAA.  This however did not work as intended,
because TYPE_ALIAS_SET == 0 was regularly lost in type merging.

But streaming an attribute works seamless, and is not lost in type
merging AFAICT.

> Also, wonder if you need to mark all types containing such arrays,
> if you couldn't just set that flag in C++ on unsigned char/std::byte
> arrays (and on anything with that attribute), have that imply alias set
> 0 on it and then let the rest of alias machinery handle aggregate types
> containing such fields.
>

Actually I set the flag only on C++ code with std::byte and
struct/union with embedded unsigned char or std::byte arrays,
but not on char arrays for instance, so I hope that it will
not pessimize the codegen too much.  The attribute does not
propagate from normal std::byte to the enclosing structure.

With LTO it is impossible to know which -std= option was used
and all C and C++ code is merged together.  So I was trying hard
to fin a way how it can work without breaking LTO.


Bernd.