[clang] Remove unused forward declarations (NFC)

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[CodeGen] Fix generation of TBAA tags for may-alias accesses

This patch fixes creating TBAA access descriptors for
may_alias-marked access types. Currently, for such types we
generate ordinary descr

[CodeGen] Fix generation of TBAA tags for may-alias accesses

This patch fixes creating TBAA access descriptors for
may_alias-marked access types. Currently, for such types we
generate ordinary descriptors with char as its access type. The
patch changes this to produce proper may-alias descriptors.

Differential Revision: https://reviews.llvm.org/D42366

llvm-svn: 325575

show more ...

[CodeGen] Decorate aggregate accesses with TBAA tags

Differential Revision: https://reviews.llvm.org/D41539

llvm-svn: 323421

Revert "[CodeGen] Add initial support for union members in TBAA"

This reverts commit r319413. See PR35503.

We can't use "union member" as the access type here like this.

llvm-svn: 319629

[CodeGen] Add initial support for union members in TBAA

The basic idea behind this patch is that since in strict aliasing
mode all accesses to union members require their outermost
enclosing union o

[CodeGen] Add initial support for union members in TBAA

The basic idea behind this patch is that since in strict aliasing
mode all accesses to union members require their outermost
enclosing union objects to be specified explicitly, then for a
couple given accesses to union members of the form

p->a.b.c...
q->x.y.z...

it is known they can only alias if both p and q point to the same
union type and offset ranges of members a.b.c... and x.y.z...
overlap. Note that the actual types of the members do not matter.

Specifically, in this patch we do the following:

* Make unions to be valid TBAA base access types. This enables
generation of TBAA type descriptors for unions.

* Encode union types as structures with a single member of a
special "union member" type. Currently we do not encode
information about sizes of types, but conceptually such union
members are considered to be of the size of the whole union.

* Encode accesses to direct and indirect union members, including
member arrays, as accesses to these special members. All
accesses to members of a union thus get the same offset, which
is the offset of the union they are part of. This means the
existing LLVM TBAA machinery is able to handle such accesses
with no changes.

While this is already an improvement comparing to the current
situation, that is, representing all union accesses as may-alias
ones, there are further changes planned to complete the support
for unions. One of them is storing information about access sizes
so we can distinct accesses to non-overlapping union members,
including accesses to different elements of member arrays.
Another change is encoding type sizes in order to make it
possible to compute offsets within constant-indexed array
elements. These enhancements will be addressed with separate
patches.

Differential Revision: https://reviews.llvm.org/D39455

llvm-svn: 319413

show more ...

[CodeGen] Collect information about sizes of accesses and access types for TBAA

The information about access and type sizes is necessary for
producing TBAA metadata in the new size-aware format. Wit

[CodeGen] Collect information about sizes of accesses and access types for TBAA

The information about access and type sizes is necessary for
producing TBAA metadata in the new size-aware format. With this
patch, D39955 and D39956 in place we should be able to change
CodeGenTBAA::createScalarTypeNode() and
CodeGenTBAA::getBaseTypeInfo() to generate metadata in the new
format under the -new-struct-path-tbaa command-line option. For
now, this new information remains unused.

Differential Revision: https://reviews.llvm.org/D40176

llvm-svn: 319012

show more ...

[CodeGen] Generate TBAA type descriptors in a more reliable manner

This patch introduces a couple of helper functions that make it
possible to handle the caching logic in a single place.

Differenti

[CodeGen] Generate TBAA type descriptors in a more reliable manner

This patch introduces a couple of helper functions that make it
possible to handle the caching logic in a single place.

Differential Revision: https://reviews.llvm.org/D39953

llvm-svn: 318752

show more ...

[CodeGen] Propagate may-alias'ness of lvalues with TBAA info

This patch fixes various places in clang to propagate may-alias
TBAA access descriptors during construction of lvalues, thus
eliminating

[CodeGen] Propagate may-alias'ness of lvalues with TBAA info

This patch fixes various places in clang to propagate may-alias
TBAA access descriptors during construction of lvalues, thus
eliminating the need for the LValueBaseInfo::MayAlias flag.

This is part of D38126 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D39008

llvm-svn: 316988

show more ...

[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

Differential Revision: https://reviews.llvm.org/D38796

llvm-svn: 315984

Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info", r315731.

With this change we fail on the clang-x86_64-linux-selfhost-modules builder.

Differential R

Revert "[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info", r315731.

With this change we fail on the clang-x86_64-linux-selfhost-modules builder.

Differential Revision: https://reviews.llvm.org/D38796

llvm-svn: 315739

show more ...

[CodeGen] EmitPointerWithAlignment() to generate TBAA info along with LValue base info

Differential Revision: https://reviews.llvm.org/D38796

llvm-svn: 315731

Refine generation of TBAA information in clang

This patch is an attempt to clarify and simplify generation and
propagation of TBAA information. The idea is to pack all values
that describe a memory

Refine generation of TBAA information in clang

This patch is an attempt to clarify and simplify generation and
propagation of TBAA information. The idea is to pack all values
that describe a memory access, namely, base type, access type and
offset, into a single structure. This is supposed to make further
changes, such as adding support for unions and array members,
easier to prepare and review.

DecorateInstructionWithTBAA() is no more responsible for
converting types to tags. These implicit conversions not only
complicate reading the code, but also suggest assigning scalar
access tags while we generally prefer full-size struct-path tags.

TBAAPathTag is replaced with TBAAAccessInfo; the latter is now
the type of the keys of the cache map that translates access
descriptors to metadata nodes.

Fixed a bug with writing to a wrong map in
getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()).

We now check for valid base access types every time we
dereference a field. The original code only checks the top-level
base type. See isValidBaseType() / isTBAAPathStruct() calls.

Some entities have been renamed to sound more adequate and less
confusing/misleading in presence of path-aware TBAA information.

Now we do not lookup twice for the same cache entry in
getAccessTagInfo().

Refined relevant comments and descriptions.

Differential Revision: https://reviews.llvm.org/D37826

llvm-svn: 315048

show more ...

[CodeGen] Unify generation of scalar and struct-path TBAA tags

This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
stru

[CodeGen] Unify generation of scalar and struct-path TBAA tags

This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.

Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.

This is part of D37826 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D38503

llvm-svn: 314979

show more ...

Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"

D37826 has been mistakenly committed where it should be the patch from D38503.

Differential Revision: https://reviews

Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"

D37826 has been mistakenly committed where it should be the patch from D38503.

Differential Revision: https://reviews.llvm.org/D38503

llvm-svn: 314978

show more ...

[CodeGen] Unify generation of scalar and struct-path TBAA tags

This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
stru

[CodeGen] Unify generation of scalar and struct-path TBAA tags

This patch makes it possible to produce access tags in a uniform
manner regardless whether the resulting tag will be a scalar or a
struct-path one. getAccessTagInfo() now takes care of the actual
translation of access descriptors to tags and can handle all
kinds of accesses. Facilities that specific to scalar accesses
are eliminated.

Some more details:
* DecorateInstructionWithTBAA() is not responsible for conversion
of types to access tags anymore. Instead, it takes an access
descriptor (TBAAAccessInfo) and generates corresponding access
tag from it.
* getTBAAInfoForVTablePtr() reworked to
getTBAAVTablePtrAccessInfo() that now returns the
virtual-pointer access descriptor and not the virtual-point
type metadata.
* Added function getTBAAMayAliasAccessInfo() that returns the
descriptor for may-alias accesses.
* getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now
it is the only way to generate access tag by a given access
descriptor. It is capable of producing both scalar and
struct-path tags, depending on options and availability of the
base access type. getTBAAScalarTagInfo() and its cache
ScalarTagMetadataCache are eliminated.
* Now that we do not need to care about whether the resulting
access tag should be a scalar or struct-path one,
getTBAAStructTypeInfo() is renamed to getBaseTypeInfo().
* Added function getTBAAAccessInfo() that constructs access
descriptor by a given QualType access type.

This is part of D37826 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D38503

llvm-svn: 314977

show more ...

[CodeGen] Introduce generic TBAA access descriptors

With this patch we implement a concept of TBAA access descriptors
that are capable of representing both scalar and struct-path
accesses in a gener

[CodeGen] Introduce generic TBAA access descriptors

With this patch we implement a concept of TBAA access descriptors
that are capable of representing both scalar and struct-path
accesses in a generic way.

This is part of D37826 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D38456

llvm-svn: 314780

show more ...

[CodeGen] Have a special function to get TBAA info for may-alias accesses

This is part of D37826 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/

[CodeGen] Have a special function to get TBAA info for may-alias accesses

This is part of D37826 reworked to be a separate patch to
simplify review.

Differential Revision: https://reviews.llvm.org/D38408

llvm-svn: 314660

show more ...

[CodeGen] Do not refer to complete TBAA info where we actually deal with just TBAA access types

This patch fixes misleading names of entities related to getting,
setting and generation of TBAA acces

[CodeGen] Do not refer to complete TBAA info where we actually deal with just TBAA access types

This patch fixes misleading names of entities related to getting,
setting and generation of TBAA access type descriptors.

This is effectively an attempt to provide a review for D37826 by
breaking it into smaller pieces.

Differential Revision: https://reviews.llvm.org/D38404

llvm-svn: 314657

show more ...

Make the remaining headers self-contained.

llvm-svn: 259507

Header guard canonicalization, clang part.

Modifications made by clang-tidy with minor tweaks.

llvm-svn: 215557

Fixed comment typo.

llvm-svn: 183598

Struct-path aware TBAA: uniformize scalar tag and path tag.

For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag.

Struct-path aware TBAA: uniformize scalar tag and path tag.

For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag. We now use the same
format: base type, access type and offset.

We also uniformize the scalar type node and the struct type node: name, a list
of pairs (offset + pointer to MDNode). For scalar type, we have a single pair.
These are to make implementaiton of aliasing rules easier.

llvm-svn: 179335

show more ...

Initial support for struct-path aware TBAA.

Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to
the actual type and 0, and are updated in EmitLValueForField.
Path-aware

Initial support for struct-path aware TBAA.

Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to
the actual type and 0, and are updated in EmitLValueForField.
Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar.
Added command line option -struct-path-tbaa.

llvm-svn: 178797

show more ...

revert r178784 since it does not have a commit message

llvm-svn: 178796