[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 ...

Filter out invalid 'target' items from being passed to LLVM

Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.

This patch also set

Filter out invalid 'target' items from being passed to LLVM

Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.

This patch also sets the 'default' for this checking to
'supported', since only X86 has implemented the support
for checking valid CPU names and Feature Names.

One test was changed to i686, since it uses a lakemont,
which would otherwise be prohibited in x86_64.

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

llvm-svn: 316783

show more ...

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

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

llvm-svn: 315984

Convert clang::LangAS to a strongly typed enum

Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as

Convert clang::LangAS to a strongly typed enum

Summary:
Convert clang::LangAS to a strongly typed enum

Currently both clang AST address spaces and target specific address spaces
are represented as unsigned which can lead to subtle errors if the wrong
type is passed. It is especially confusing in the CodeGen files as it is
not possible to see what kind of address space should be passed to a
function without looking at the implementation.
I originally made this change for our LLVM fork for the CHERI architecture
where we make extensive use of address spaces to differentiate between
capabilities and pointers. When merging the upstream changes I usually
run into some test failures or runtime crashes because the wrong kind of
address space is passed to a function. By converting the LangAS enum to a
C++11 we can catch these errors at compile time. Additionally, it is now
obvious from the function signature which kind of address space it expects.

I found the following errors while writing this patch:

- ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address
space to TargetInfo::getPointer{Width,Align}()
- TypePrinter::printAttributedAfter() prints the numeric value of the
clang AST address space instead of the target address space.
However, this code is not used so I kept the current behaviour
- initializeForBlockHeader() in CGBlocks.cpp was passing
LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}()
- CodeGenFunction::EmitBlockLiteral() was passing a AST address space to
TargetInfo::getPointerWidth()
- CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space
to Qualifiers::addAddressSpace()
- CGOpenMPRuntimeNVPTX::getParameterAddress() was using
llvm::Type::getPointerTo() with a AST address space
- clang_getAddressSpace() returns either a LangAS or a target address
space. As this is exposed to C I have kept the current behaviour and
added a comment stating that it is probably not correct.

Other than this the patch should not cause any functional changes.

Reviewers: yaxunl, pcc, bader

Reviewed By: yaxunl, bader

Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits

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

llvm-svn: 315871

show more ...

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 ...

Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.

Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
middle-end.

This change emits the section information for all targets.

Patch By: Elizabeth Andrews

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

llvm-svn: 314262

show more ...

CodeGenModule: Adapt to LLVM TargetLibraryInfo changes

Adapt to LLVM TargetLibraryInfo changes in r314185.

See also https://reviews.llvm.org/D38106 and https://reviews.llvm.org/D37891

llvm-svn: 31

CodeGenModule: Adapt to LLVM TargetLibraryInfo changes

Adapt to LLVM TargetLibraryInfo changes in r314185.

See also https://reviews.llvm.org/D38106 and https://reviews.llvm.org/D37891

llvm-svn: 314187

show more ...

Allow specifying sanitizers in blacklists

Summary:
This is the follow-up patch to D37924.

This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which

Allow specifying sanitizers in blacklists

Summary:
This is the follow-up patch to D37924.

This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:

[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*

The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.

Reviewers: pcc, kcc, eugenis, vsk

Reviewed By: eugenis

Subscribers: dberris, cfe-commits, mgorny

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

llvm-svn: 314171

show more ...

[Coverage] Add an option to emit limited coverage info

Add an option to emit limited coverage info for unused decls. It's just a
cl::opt for now to allow us to experiment quickly.

When building llc

[Coverage] Add an option to emit limited coverage info

Add an option to emit limited coverage info for unused decls. It's just a
cl::opt for now to allow us to experiment quickly.

When building llc, this results in an 84% size reduction in the llvm_covmap
section, and a similar size reduction in the llvm_prf_names section. In
practice I expect the size reduction to be roughly quadratic with the size of
the program.

The downside is that coverage for headers will no longer be complete. This will
make the line/function/region coverage metrics incorrect, since they will be
artificially high. One mitigation would be to somehow disable those metrics
when using limited-coverage=true.

This is related to: llvm.org/PR34533 (make SourceBasedCodeCoverage scale)

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

llvm-svn: 314002

show more ...

[codeview] omit debug locations for nested exprs unless column info enabled

Summary:
Microsoft Visual Studio expects debug locations to correspond to
statements. We used to emit locations for expres

[codeview] omit debug locations for nested exprs unless column info enabled

Summary:
Microsoft Visual Studio expects debug locations to correspond to
statements. We used to emit locations for expressions nested inside statements.
This would confuse the debugger, causing it to stop multiple times on the
same line and breaking the "step into specific" feature. This change inhibits
the emission of debug locations for nested expressions when emitting CodeView
debug information, unless column information is enabled.

Fixes PR34312.

Reviewers: rnk, zturner

Reviewed By: rnk

Subscribers: majnemer, echristo, aprantl, cfe-commits

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

llvm-svn: 312965

show more ...

Emit static constexpr member as available_externally definition

By exposing the constant initializer, the optimizer can fold many
of these constructs.

This is a recommit of r311857 that was reverte

Emit static constexpr member as available_externally definition

By exposing the constant initializer, the optimizer can fold many
of these constructs.

This is a recommit of r311857 that was reverted in r311898 because
an assert was hit when building Chromium.
We have to take into account that the GlobalVariable may be first
created with a different type than the initializer. This can
happen for example when the variable is a struct with tail padding
while the initializer does not have padding. In such case, the
variable needs to be destroyed an replaced with a new one with the
type of the initializer.

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

llvm-svn: 312512

show more ...

Revert r311857 "Emit static constexpr member as available_externally definition"

It caused PR759744.

> Emit static constexpr member as available_externally definition
>
> By exposing the constant i

Revert r311857 "Emit static constexpr member as available_externally definition"

It caused PR759744.

> Emit static constexpr member as available_externally definition
>
> By exposing the constant initializer, the optimizer can fold many
> of these constructs.
>
> Differential Revision: https://reviews.llvm.org/D34992

llvm-svn: 311898

show more ...

Emit static constexpr member as available_externally definition

By exposing the constant initializer, the optimizer can fold many
of these constructs.

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

Emit static constexpr member as available_externally definition

By exposing the constant initializer, the optimizer can fold many
of these constructs.

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

llvm-svn: 311857

show more ...

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit constant initializers that have
ignorable side-effects, or doing the majority of an initialization
in-place and then patching up the last few things with calls. But for
now this is mostly just a refactoring.

llvm-svn: 310964

show more ...

[OpenCL] Allow targets to select address space per type

Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such
that targets can select the address space per type.

No functional change

[OpenCL] Allow targets to select address space per type

Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such
that targets can select the address space per type.

No functional changes intended.

Initial patch by Simon Perretta.

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

llvm-svn: 310911

show more ...

CodeGenModule.cpp: [PR33810][Modules] Remove an assertion that confirms MangledDeclNames[CanonicalGD] might be still empty.

FIXME: It is accepted that MangledDeclNames[CanonicalGD] is overwritten he

CodeGenModule.cpp: [PR33810][Modules] Remove an assertion that confirms MangledDeclNames[CanonicalGD] might be still empty.

FIXME: It is accepted that MangledDeclNames[CanonicalGD] is overwritten here?
llvm-svn: 309504

show more ...

CodeGenModule.cpp: [PR33810][Modules] Avoid reusing FoundStr to try to fix crash.

MangledDeclNames might grow up and be reallocated when it were reused by reentering CodeGenModule::getMangledName().

CodeGenModule.cpp: [PR33810][Modules] Avoid reusing FoundStr to try to fix crash.

MangledDeclNames might grow up and be reallocated when it were reused by reentering CodeGenModule::getMangledName().

llvm-svn: 309501

show more ...