[PGO] Don't reference functions unless value profiling is enabled

This reduces the size of chrome.dll.pdb built with optimizations,
coverage, and line table info from 4,690,210,816 to 2,181,128,192,

[PGO] Don't reference functions unless value profiling is enabled

This reduces the size of chrome.dll.pdb built with optimizations,
coverage, and line table info from 4,690,210,816 to 2,181,128,192, which
makes it possible to fit under the 4GB limit.

This change can greatly reduce binary size in coverage builds, which do
not need value profiling. IR PGO builds are unaffected. There is a minor
behavior change for frontend PGO.

PGO and coverage both use InstrProfiling to create profile data with
counters. PGO records the address of each function in the __profd_
global. It is used later to map runtime function pointer values back to
source-level function names. Coverage does not appear to use this
information.

Recording the address of every function with code coverage drastically
increases code size. Consider this program:

void foo();
void bar();
inline void inlineMe(int x) {
if (x > 0)
foo();
else
bar();
}
int getVal();
int main() { inlineMe(getVal()); }

With code coverage, the InstrProfiling pass runs before inlining, and it
captures the address of inlineMe in the __profd_ global. This greatly
increases code size, because now the compiler can no longer delete
trivial code.

One downside to this approach is that users of frontend PGO must apply
the -mllvm -enable-value-profiling flag globally in TUs that enable PGO.
Otherwise, some inline virtual method addresses may not be recorded and
will not be able to be promoted. My assumption is that this mllvm flag
is not popular, and most frontend PGO users don't enable it.

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

show more ...

[NFC] Make non-modifying members const.

Implementing the likelihood attributes for the iteration statements adds
a new helper function. This function can't be const qualified since
these non-modifyi

[NFC] Make non-modifying members const.

Implementing the likelihood attributes for the iteration statements adds
a new helper function. This function can't be const qualified since
these non-modifying members aren't const qualified.

show more ...

[CodeGenPGO] Fix shadow variable warning. NFC.

Fix uninitialized variable warning in CodeGenPGO constructor. NFCI.

llvm-svn: 373526

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

Move CodeGenOptions from Frontend to Basic

Basic uses CodeGenOptions and should not depend on Frontend.

llvm-svn: 348827

Remove a dead field. NFC.

Suggested by Adam Folwarczny!

llvm-svn: 301250

Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)

2nd attempt: the first was in r296231, but it had a use after lifetime
bug.

Clang has logic to lower certain conditi

Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)

2nd attempt: the first was in r296231, but it had a use after lifetime
bug.

Clang has logic to lower certain conditional expressions directly into llvm
select instructions. However, it does not emit the correct profile counter
increment as it does this: it emits an unconditional increment of the counter
for the 'then branch', even if the value selected is from the 'else branch'
(this is PR32019).

That means, given the following snippet, we would report that "0" is selected
twice, and that "1" is never selected:

int f1(int x) {
return x ? 0 : 1;
^2 ^0
}

f1(0);
f1(1);

Fix the problem by using the instrprof_increment_step intrinsic to do the
proper increment.

llvm-svn: 296245

show more ...

Revert "[profiling] Fix profile counter increment when emitting selects (PR32019)"

This reverts commit r296231. It causes an assertion failure on 32-bit
machines

clang: /export/users/atombot/llvm/c

Revert "[profiling] Fix profile counter increment when emitting selects (PR32019)"

This reverts commit r296231. It causes an assertion failure on 32-bit
machines

clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed.
llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa)
llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e)
SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2)
__restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0)
__GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
__GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0
__assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0
(/lib64/libc.so.6+0x3f1c82e622)
llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a)
clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891)

llvm-svn: 296234

show more ...

[profiling] Fix profile counter increment when emitting selects (PR32019)

Clang has logic to lower certain conditional expressions directly into
llvm select instructions. However, it does not emit t

[profiling] Fix profile counter increment when emitting selects (PR32019)

Clang has logic to lower certain conditional expressions directly into
llvm select instructions. However, it does not emit the correct profile
counter increment as it does this: it emits an unconditional increment
of the counter for the 'then branch', even if the value selected is from
the 'else branch' (this is PR32019).

That means, given the following snippet, we would report that "0" is
selected twice, and that "1" is never selected:

int f1(int x) {
return x ? 0 : 1;
^2 ^0
}

f1(0);
f1(1);

Fix the problem by using the instrprof_increment_step intrinsic to do
the proper increment.

llvm-svn: 296231

show more ...

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

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

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

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

llvm-svn: 275882

show more ...

[Coverage] Move logic to skip decl's into a helper (NFC)

llvm-svn: 275120

revert SVN r265702, r265640

Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is a

revert SVN r265702, r265640

Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic". This addresses Richard's
post-commit review comments. This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.

llvm-svn: 265806

show more ...

Basic: move CodeGenOptions from Frontend

This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions i

Basic: move CodeGenOptions from Frontend

This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.

llvm-svn: 265702

show more ...

[PGO] Windows buildbot failure fix. [NFC]

llvm-svn: 258652

Clang changes for value profiling

Differential Revision: http://reviews.llvm.org/D8940

llvm-svn: 258650

[PGO] Instrument only base constructors and destructors.

Constructors and destructors may be represented by several functions
in IR. Only base structors correspond to source code, others are
small p

[PGO] Instrument only base constructors and destructors.

Constructors and destructors may be represented by several functions
in IR. Only base structors correspond to source code, others are
small pieces of code and eventually call the base variant. In this
case instrumentation of non-base structors has little sense, this
fix remove it. Now profile data of a declaration corresponds to
exactly one function in IR, it agrees with the current logic of the
profile data loading.

This change fixes PR24996.

Differential Revision: http://reviews.llvm.org/D15158

llvm-svn: 254876

show more ...

[PGO] Removed unused code. [NFC]

llvm-svn: 253404

[CodeGen] Remove dead code. NFC.

llvm-svn: 250418

InstrProf: Cede ownership of createProfileWeights to CGF

The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this

InstrProf: Cede ownership of createProfileWeights to CGF

The fact that PGO has a say in how these branch weights are determined
isn't interesting to most of CodeGen, so it makes more sense for this
API to be accessible via CodeGenFunction rather than CodeGenPGO.

llvm-svn: 236380

show more ...

InstrProf: Use a locally tracked current count in ComputeRegionCounts

No functional change. This just makes it more obvious that the logic
in ComputeRegionCounts only depends on the counter map and

InstrProf: Use a locally tracked current count in ComputeRegionCounts

No functional change. This just makes it more obvious that the logic
in ComputeRegionCounts only depends on the counter map and local
state.

llvm-svn: 236370

show more ...

InstrProf: Replace the RegionCounter class with a simpler direct approach

This removes the RegionCounter class, which is only used as a helper
in teh ComputeRegionCounts stmt visitor. This class is

InstrProf: Replace the RegionCounter class with a simpler direct approach

This removes the RegionCounter class, which is only used as a helper
in teh ComputeRegionCounts stmt visitor. This class is just an extra
layer of abstraction that makes the code harder to follow at this
point, and removing it makes the logic quite a bit more direct.

llvm-svn: 236364

show more ...

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses else

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.

llvm-svn: 235664

show more ...

InstrProf: Simplify getStmtCount by using an Optional

llvm-svn: 234750

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

ll

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

llvm-svn: 223683

show more ...