This reverts commit r317951 and r317952. The new test is aborting on
some bots and I'll need to investigate later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317959 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The LTO Config field wasn't being set when invoking a ThinLTO backend
via clang (i.e. for distributed builds).
Reviewers: danielcdh
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D39923
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317951 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Augment SanitizerCoverage to insert maximum stack depth tracing for
use by libFuzzer. The new instrumentation is enabled by the flag
-fsanitize-coverage=stack-depth and is compatible with the existing
trace-pc-guard coverage. The user must also declare the following
global variable in their code:
thread_local uintptr_t __sancov_lowest_stack
https://bugs.llvm.org/show_bug.cgi?id=33857
Reviewers: vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D36839
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@311186 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The new PM needs to invoke add-discriminator pass when building with -fdebug-info-for-profiling.
Reviewers: chandlerc, davidxl
Reviewed By: chandlerc
Subscribers: sanjoy, cfe-commits
Differential Revision: https://reviews.llvm.org/D35746
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@309282 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, -fno-builtin and friends doesn't work. Added the obvious
RUN lines to the test for -fno-builtin and they pass now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@308967 91177308-0d34-0410-b5e6-96231b3b80d8
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.
Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).
Differential Revision: https://reviews.llvm.org/D34846
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306786 91177308-0d34-0410-b5e6-96231b3b80d8
Previously it doesn't actually invoke the designated new PM builder
functions.
This patch moves NameAnonGlobalPass out from PassBuilder, as Chandler
points out that PassBuilder is used for non-O0 builds, and for
optimizations only.
Differential Revision: https://reviews.llvm.org/D34728
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@306756 91177308-0d34-0410-b5e6-96231b3b80d8
If a regular LTO module has a summary index, then instead of linking
it into the combined regular LTO module right away, add it to the
combined summary index and associate it with a special module that
represents the combined regular LTO module.
Any such modules are linked during LTO::run(), at which time we use
the results of summary-based dead stripping to control whether to
link prevailing symbols.
Differential Revision: https://reviews.llvm.org/D33922
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305482 91177308-0d34-0410-b5e6-96231b3b80d8
This is tied with the LLVM side of the change to expose the debug
information compression types to clang. We now track the compression
type as an enumeration rather than a boolean. We still use the same
value (GNU) that we did previously. This is in preparation to support
passing down the compression type and switch it based on the command
line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305039 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This patch teaches clang to use and propagate new PM in ThinLTO.
Reviewers: davide, chandlerc, tejohnson
Subscribers: mehdi_amini, Prazek, inglorion, cfe-commits
Differential Revision: https://reviews.llvm.org/D33692
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@304496 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Clang changes to remove this option and replace with a parameter
always set in the context of a ThinLTO distributed backend.
Depends on D33133.
Reviewers: pcc
Subscribers: mehdi_amini, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D33134
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302940 91177308-0d34-0410-b5e6-96231b3b80d8
This feature is subtly broken when the linker is gold 2.26 or
earlier. See the following bug for details:
https://sourceware.org/bugzilla/show_bug.cgi?id=19002
Since the decision needs to be made at compilation time, we can not
test the linker version. The flag is off by default on ELF targets,
and on otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302591 91177308-0d34-0410-b5e6-96231b3b80d8
When profiling a no-op incremental link of Chromium I found that the functions
computeImportForFunction and computeDeadSymbols were consuming roughly 10% of
the profile. The goal of this change is to improve the performance of those
functions by changing the map lookups that they were previously doing into
pointer dereferences.
This is achieved by changing the ValueInfo data structure to be a pointer to
an element of the global value map owned by ModuleSummaryIndex, and changing
reference lists in the GlobalValueSummary to hold ValueInfos instead of GUIDs.
This means that a ValueInfo will take a client directly to the summary list
for a given GUID.
Differential Revision: https://reviews.llvm.org/D32471
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302108 91177308-0d34-0410-b5e6-96231b3b80d8
This change restores pre-r301225 behavior, where linker GC compatible global
instrumentation was used on COFF targets disregarding -f(no-)data-sections and/or
/Gw flags.
This instrumentation puts each global in a COMDAT with an ASan descriptor for that global.
It effectively enables -fdata-sections, but limits it to ASan-instrumented globals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301374 91177308-0d34-0410-b5e6-96231b3b80d8
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@301063 91177308-0d34-0410-b5e6-96231b3b80d8
This restores the behavior prior to D31167 where the code-gen default was
FPC_On which mapped to FPOpFusion::Standard. After merging the FE
state (on/off) and the code-gen state (on/fast/off), the default became off to
match the front-end.
In other words, the front-end controls when to fuse along the language
standards and the backend shouldn't override this by splitting fused
intrinsics as FPOpFusion::Strict would imply.
Differential Revision: https://reviews.llvm.org/D32301
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300858 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Use PreCodeGenModuleHook to invoke the correct writer when emitting LLVM
IR, returning false to skip codegen from within thinBackend.
Reviewers: pcc, mehdi_amini
Subscribers: Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D31534
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299274 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This involved refactoring out pieces of
EmitAssemblyHelper::CreateTargetMachine for use in runThinLTOBackend.
Subsumes D31114.
Reviewers: mehdi_amini, pcc
Subscribers: Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D31508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299152 91177308-0d34-0410-b5e6-96231b3b80d8
FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast). This makes it universally the type for the contractable info
across the front-end:
* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.
Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
* For "on", FMA folding was performed by the front-end
* For "fast", we simply forwarded the flag to TargetOptions to handle it in
LLVM
Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
---
This is a recommit of r299027 with an adjustment to the test
CodeGenCUDA/fp-contract.cu. The test assumed that even
though -ffp-contract=on is passed FE-based folding of FMA won't happen.
This is obviously wrong since the user is asking for this explicitly with the
option. CUDA is different that -ffp-contract=fast is on by default.
The test used to "work" because contract=fast and contract=on were maintained
separately and we didn't fold in the FE because contract=fast was on due to
the target-default. This patch consolidates the contract=on/fast/off state
into a ternary state hence the change in behavior.
---
Differential Revision: https://reviews.llvm.org/D31167
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299033 91177308-0d34-0410-b5e6-96231b3b80d8
FPContractModeKind is the codegen option flag which is already ternary (off,
on, fast). This makes it universally the type for the contractable info
across the front-end:
* In FPOptions (i.e. in the Sema + in the expression nodes).
* In LangOpts::DefaultFPContractMode which is the option that initializes
FPOptions in the Sema.
Another way to look at this change is that before fp-contractable on/off were
the only states handled to the front-end:
* For "on", FMA folding was performed by the front-end
* For "fast", we simply forwarded the flag to TargetOptions to handle it in
LLVM
Now off/on/fast are all exposed because for fast we will generate
fast-math-flags during CodeGen.
This is toward moving fp-contraction=fast from an LLVM TargetOption to a
FastMathFlag in order to fix PR25721.
Differential Revision: https://reviews.llvm.org/D31167
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299027 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Clang companion patch to LLVM patch D31027, which adds support
for emitting minimized bitcode file for use in the thin link step.
Add a cc1 option -fthin-link-bitcode=<file> to trigger this behavior.
Depends on D31027.
Reviewers: mehdi_amini, pcc
Subscribers: cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31050
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298639 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in pro
file, thus we do not want to inline hot callsites in the first phase.
Reviewers: tejohnson, eraman
Reviewed By: tejohnson
Subscribers: mehdi_amini, cfe-commits, Prazek
Differential Revision: https://reviews.llvm.org/D31202
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298429 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: AddDiscriminator pass is only useful for sample pgo. This patch restricts AddDiscriminator to -fdebug-info-for-profiling so that it does not introduce unecessary debug size increases for non-sample-pgo builds.
Reviewers: dblaikie, aprantl
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30220
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@295764 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LF_". (Unfortunately, a scoped enum is not sufficient to override macros.)
These changes are for clang. See https://reviews.llvm.org/D28476 for LLVM.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28477
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292849 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: LTO backend will not invoke SampleProfileLoader pass even if -fprofile-sample-use is specified. This patch passes the flag down so that pass manager can add the SampleProfileLoader pass correctly.
Reviewers: mehdi_amini, tejohnson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28588
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291870 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: LTO backend will not invoke SampleProfileLoader pass even if -fprofile-sample-use is specified. This patch passes the flag down so that pass manager can add the SampleProfileLoader pass correctly.
Reviewers: mehdi_amini, tejohnson
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28588
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291774 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In order to simplify distributed build system integration, where actions
may be scheduled before the Thin Link which determines the list of
objects selected by the linker. The gold plugin currently will emit
0-sized index files for objects not selected by the link, to enable
checking for expected output files by the build system. If the build
system then schedules a backend action for these bitcode files, we want
to be able to fall back to normal compilation instead of failing.
Fallback is enabled under an option in LLVM (D28410), in which case a
nullptr is returned from llvm::getModuleSummaryIndexForFile. Clang can
just proceed with non-ThinLTO compilation in that case.
I am investigating whether this can be addressed in our build system,
but that is a longer term fix and so this enables a workaround in the
meantime.
Reviewers: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28362
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291303 91177308-0d34-0410-b5e6-96231b3b80d8
inline assembly may use the `.include` directive to include other
content into the file. Without the integrated assembler, the `-I` group
gets passed to the assembler. Emulate this by collecting the header
search paths and passing them to the IAS.
Resolves PR24811!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291123 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We can simply import all external values with summaries included in
the individual index file created for the distributed backend job,
as only those are added to the individual index file created by the
WriteIndexesThinBackend (in addition to summaries for the original
module, which are skipped here).
While computing the cross module imports on this index would come to
the same conclusion as the original thin link import logic, it is
unnecessary work. And when tuning, it avoids the need to pass the
same function importing parameters (e.g. -import-instr-limit) to
both the thin link and the backends (otherwise they won't make the
same decisions).
Reviewers: mehdi_amini, pcc
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28139
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290674 91177308-0d34-0410-b5e6-96231b3b80d8
This is kind of funny because I specifically did work to make this easy
and then it didn't actually get implemented.
I've also ported a set of tests that rely on this functionality to run
with the new PM as well as the old PM so that we don't mess this up in
the future.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290558 91177308-0d34-0410-b5e6-96231b3b80d8
manager, and a code path to use it.
The option is actually a top-level option but does contain
'experimental' in the name. This is the compromise suggested by Richard
in discussions. We expect this option will be around long enough and
have enough users towards the end that it merits not being relegated to
CC1, but it still needs to be clear that this option will go away at
some point.
The backend code is a fresh codepath dedicated to handling the flow with
the new pass manager. This was also Richard's suggested code structuring
to essentially leave a clean path for development rather than carrying
complexity or idiosyncracies of how we do things just to share code with
the parts of this in common with the legacy pass manager. And it turns
out, not much is really in common even though we use the legacy pass
manager for codegen at this point.
I've switched a couple of tests to run with the new pass manager, and
they appear to work. There are still plenty of bugs that need squashing
(just with basic experiments I've found two already!) but they aren't in
this code, and the whole point is to expose the necessary hooks to start
experimenting with the pass manager in more realistic scenarios.
That said, I want to *strongly caution* anyone itching to play with
this: it is still *very shaky*. Several large components have not yet
been shaken down. For example I have bugs in both the always inliner and
inliner that I have already spotted and will be fixing independently.
Still, this is a fun milestone. =D
One thing not in this patch (but that might be very reasonable to add)
is some level of support for raw textual pass pipelines such as what
Sean had a patch for some time ago. I'm mostly interested in the more
traditional flow of getting the IR out of Clang and then running it
through opt, but I can see other use cases so someone may want to add
it.
And of course, *many* features are not yet supported!
- O1 is currently more like O2
- None of the sanitizers are wired up
- ObjC ARC optimizer isn't wired up
- ...
So plenty of stuff still lef to do!
Differential Revision: https://reviews.llvm.org/D28077
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290450 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-inline-functions, -O0, and optnone.
These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.
Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.
I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.
One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.
Differential Revision: https://reviews.llvm.org/D28053
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290398 91177308-0d34-0410-b5e6-96231b3b80d8
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290392 91177308-0d34-0410-b5e6-96231b3b80d8
BackendUtil.cpp uses llvm::SmallSet but did not include the header. It was
included indirectly, but this will change once the AssumptionCache is removed.
NFC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289752 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We used to create SampleProfileLoader pass in clang. This makes LTO/ThinLTO unable to add this pass in the linker plugin. This patch moves the SampleProfileLoader pass creation from
clang to llvm pass manager builder.
Reviewers: tejohnson, davidxl, dnovillo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D27744
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289715 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We used to create SampleProfileLoader pass in clang. This makes LTO/ThinLTO unable to add this pass in the linker plugin. This patch moves the SampleProfileLoader pass creation from
clang to llvm pass manager builder.
Reviewers: tejohnson, davidxl, dnovillo
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D27744
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289670 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, TargetLibraryInfoWrapperPass is inserted by PMBuilder.
However, some passes are inserted manually before the PMBuilder
ones - if any of them happens to use TargetLibraryInfoWrapperPass,
it'll get a default-constructed one, with an unknown target triple.
This happens to InstrProfiling in D21736, breaking it.
Differential Revision: http://reviews.llvm.org/D21737
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@287688 91177308-0d34-0410-b5e6-96231b3b80d8
The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.
Change clang uses to the appropriate split header(s).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286567 91177308-0d34-0410-b5e6-96231b3b80d8
The motivation for the change is that we can't have pseudo-global settings
for codegen living in TargetOptions because that doesn't work with LTO.
Ideally, these reciprocal attributes will be moved to the instruction-level
via FMF, metadata, or something else. But making them function attributes is
at least an improvement over the current state.
I'm committing this patch ahead of the related LLVM patch to avoid bot failures,
but if that patch needs to be reverted, then this should be reverted too.
Differential Revision: https://reviews.llvm.org/D24815
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283251 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
With this commit simple coroutines can be created in plain C using coroutine builtins.
Reviewers: rnk, EricWF, rsmith
Subscribers: modocache, mgorny, mehdi_amini, beanz, cfe-commits
Differential Revision: https://reviews.llvm.org/D24373
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283155 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We previously relies on InstructionCombining pass to remove invoke instructions. Now that we can inline invoke instructions correctly, we do not need these passes any more.
Reviewers: dnovillo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24730
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281910 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This changes clang to use the llvm::lto::thinBackend function instead of
its own less comprehensive ThinLTO backend implementation.
Patch by Peter Collingbourne
Reviewers: tejohnson, mehdi_amini
Subscribers: cfe-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D21545
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278541 91177308-0d34-0410-b5e6-96231b3b80d8
This patch (with the corresponding ARM backend patch) adds support for
some new relocation models:
* Read-only position independence (ROPI): Code and read-only data is accessed
PC-relative. The offsets between all code and RO data sections are known at
static link time.
* Read-write position independence (RWPI): Read-write data is accessed relative
to a static base register. The offsets between all writeable data sections
are known at static link time.
These two modes are independent (they specify how different objects
should be addressed), so they can be used individually or together.
These modes are intended for bare-metal systems or systems with small
real-time operating systems. They are designed to avoid the need for a
dynamic linker, the only initialisation required is setting the static
base register to an appropriate value for RWPI code.
There is one C construct not currently supported by these modes: global
variables initialised to the address of another global variable or
function, where that address is not known at static-link time. There are
a few possible ways to solve this:
* Disallow this, and require the user to write their own initialisation
function if they need variables like this.
* Emit dynamic initialisers for these variables in the compiler, called from
the .init_array section (as is currently done for C++ dynamic initialisers).
We have a patch to do this, described in my original RFC email
(http://lists.llvm.org/pipermail/llvm-dev/2015-December/093022.html), but the
feedback from that RFC thread was that this is not something that belongs in
clang.
* Use a small dynamic loader to fix up these variables, by adding the
difference between the load and execution address of the relevant section.
This would require linker co-operation to generate a table of addresses that
need fixing up.
Differential Revision: https://reviews.llvm.org/D23196
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278016 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the CompilerInstance::createOutputFile function to return
a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_ostream
implicitly owned by the CompilerInstance. This in most cases required that
I move ownership of the output stream to the relevant ASTConsumer.
The motivation for this change is to allow BackendConsumer to be a client
of interfaces such as D20268 which take ownership of the output stream.
Differential Revision: http://reviews.llvm.org/D21537
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275507 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: InstCombine needs to be performed after simplifycfg and sroa, otherwise it may make bad optimization decisions.
Reviewers: davidxl, wmi, dnovillo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21568
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273606 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for /Ob1 (and equivalent -finline-hint-functions), which enable
inlining only for functions marked inline, either explicitly (via inline
keyword, for example), or implicitly (function definition in class body,
for example).
This works by enabling inlining pass, and adding noinline attribute to
every function not marked inline.
Patch by Rudy Pons <rudy.pons@ilod.org>!
Differential Revision: http://reviews.llvm.org/D20647
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273440 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We need to call PruneEH pass before AutoFDO pass so that some EH-related calls can get inlined in Sample Profile pass.
Reviewers: davidxl, dnovillo
Subscribers: junbuml, llvm-commits
Differential Revision: http://reviews.llvm.org/D21197
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273298 91177308-0d34-0410-b5e6-96231b3b80d8
Teresa Johnson