Add -finstrument-function-entry-bare flag

This is an instrumentation flag that's similar to
-finstrument-functions, but it only inserts calls on function entry, the
calls are inserted post-inlining,

Add -finstrument-function-entry-bare flag

This is an instrumentation flag that's similar to
-finstrument-functions, but it only inserts calls on function entry, the
calls are inserted post-inlining, and they don't take any arugments.

This is intended for users who want to instrument function entry with
minimal overhead.

(-pg would be another alternative, but forces frame pointer emission and
affects link flags, so is probably best left alone to be used for
generating gcov data.)

Differential revision: https://reviews.llvm.org/D40276

llvm-svn: 318785

show more ...

Switch -mcount and -finstrument-functions to emit EnterExitInstrumenter attributes

This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to als

Switch -mcount and -finstrument-functions to emit EnterExitInstrumenter attributes

This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.

It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.

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

llvm-svn: 318199

show more ...

[coroutines] Promote cleanup.dest.slot allocas to registers to avoid storing it in the coroutine frame

Summary:
We don't want to store cleanup dest slot saved into the coroutine frame (as some of th

[coroutines] Promote cleanup.dest.slot allocas to registers to avoid storing it in the coroutine frame

Summary:
We don't want to store cleanup dest slot saved into the coroutine frame (as some of the cleanup code may
access them after coroutine frame destroyed).

This is an alternative to https://reviews.llvm.org/D37093

It is possible to do this for all functions, but, cursory check showed that in -O0, we get slightly longer function (by 1-3 instructions), thus, we are only limiting cleanup.dest.slot elimination to coroutines.

Reviewers: rjmccall, hfinkel, eric_niebler

Reviewed By: eric_niebler

Subscribers: EricWF, cfe-commits

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

llvm-svn: 317981

show more ...

[CodeGen] match new fast-math-flag method: isFast()

This corresponds to LLVM commiti r317488:

If that commit is reverted, this commit will also need to be reverted.

llvm-svn: 317489

[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

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

[ubsan] Don't emit function signatures for non-static member functions

The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (con

[ubsan] Don't emit function signatures for non-static member functions

The function sanitizer only checks indirect calls through function
pointers. This excludes all non-static member functions (constructor
calls, calls through thunks, etc. all use a separate code path). Don't
emit function signatures for functions that won't be checked.

Apart from cutting down on code size, this should fix a regression on
Linux caused by r313096. For context, see the mailing list discussion:

r313096 - [ubsan] Function Sanitizer: Don't require writable text segments

Testing: check-clang, check-ubsan

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

llvm-svn: 315786

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

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

This patch should not bring in any functional changes.

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

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

This patch should not bring in any functional changes.

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

llvm-svn: 315708

show more ...

[CodeGen] Generate TBAA info along with LValue base info

This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial wa

[CodeGen] Generate TBAA info along with LValue base info

This patch enables explicit generation of TBAA information in all
cases where LValue base info is propagated or constructed in
non-trivial ways. Eventually, we will consider each of these
cases to make sure the TBAA information is correct and not too
conservative. For now, we just fall back to generating TBAA info
from the access type.

This patch should not bring in any functional changes.

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

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

llvm-svn: 315575

show more ...

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

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

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

[ubsan] Function Sanitizer: Don't require writable text segments

This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the wa

[ubsan] Function Sanitizer: Don't require writable text segments

This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the way RTTI is stored into
function prologue data.

On Darwin, addresses stored in prologue data can't require run-time fixups and
must be PC-relative. Run-time fixups are undesirable because they necessitate
writable text segments, which can lead to security issues. And absolute
addresses are undesirable because they break PIE mode.

The fix is to create a private global which points to the RTTI, and then to
encode a PC-relative reference to the global into prologue data.

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

llvm-svn: 313096

show more ...

Expose -mllvm -accurate-sample-profile to clang.

Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size

Expose -mllvm -accurate-sample-profile to clang.

Summary: With accurate sample profile, we can do more aggressive size optimization. For some size-critical application, this can reduce the text size by 20%

Reviewers: davidxl, rsmith

Reviewed By: davidxl, rsmith

Subscribers: mehdi_amini, eraman, sanjoy, cfe-commits

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

llvm-svn: 311707

show more ...

[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any).

[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any).

Do not sanitize the 'this' pointer of a member call operator for a lambda with
no capture-default, since that call operator can legitimately be called with a
null this pointer from the static invoker function. Any actual call with a null
this pointer should still be caught in the caller (if it is being sanitized).

This reinstates r311589 (reverted in r311680) with the above fix.

llvm-svn: 311695

show more ...

Revert "[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (

Revert "[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any)."

This reverts commit r311589 because of bot breakage.
http://green.lab.llvm.org/green/job/clang-stage2-cmake-RgSan_check/4115/consoleFull#15752874848254eaf0-7326-4999-85b0-388101f2d404.

llvm-svn: 311680

show more ...

[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any).

[ubsan] PR34266: When sanitizing the 'this' value for a member function that happens to be a lambda call operator, use the lambda's 'this' pointer, not the captured enclosing 'this' pointer (if any).

llvm-svn: 311589

show more ...

Clean up some lambda conversion operator code, NFC

We don't need special handling in CodeGenFunction::GenerateCode for
lambda block pointer conversion operators anymore. The conversion
operator emis

Clean up some lambda conversion operator code, NFC

We don't need special handling in CodeGenFunction::GenerateCode for
lambda block pointer conversion operators anymore. The conversion
operator emission code immediately calls back to the generic
EmitFunctionBody.

Rename EmitLambdaStaticInvokeFunction to EmitLambdaStaticInvokeBody for
better consistency with the other Emit*Body methods.

I'm preparing to do something about PR28299, which touches this code.

llvm-svn: 310145

show more ...

Reland "CFI: blacklist STL allocate() from unrelated-casts"

Reland r310097 with a fix for a debug assertion in NamedDecl.getName()

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

llvm-svn:

Reland "CFI: blacklist STL allocate() from unrelated-casts"

Reland r310097 with a fix for a debug assertion in NamedDecl.getName()

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

llvm-svn: 310132

show more ...

Revert "Reland "CFI: blacklist STL allocate() from unrelated-casts""

This reverts commit r310105.

llvm-svn: 310121