| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by: krisb
Reviewers: teemperor
Reviewed By: teemperor
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D43809
llvm-svn: 326566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ThinLTO compilation may decide not to split module and keep at as regular LTO.
In this can this module already processed during indexing and already a part of
merged object file. So here we can just skip it.
Reviewers: pcc, tejohnson
Reviewed By: tejohnson
Subscribers: mehdi_amini, inglorion, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D42680
llvm-svn: 325410
|
|
|
|
|
|
|
| |
We don't generate remarks during inline assembly parsing so no need to handle
these for now.
llvm-svn: 315643
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
|
|
|
|
| |
llvm-svn: 314873
|
|
|
|
|
|
|
| |
This class isn't similar to anything from the STL, so it shouldn't use
the STL naming conventions.
llvm-svn: 314050
|
|
|
|
|
|
|
| |
This is used by the new closure-based variant of
OptimizationRemarkEmitter::emit().
llvm-svn: 313693
|
|
|
|
|
|
|
| |
Apparently these weren't really working. I added test coverage and fixed the
typo in the name and the parameter.
llvm-svn: 313653
|
|
|
|
|
|
| |
change is as per https://reviews.llvm.org/D33514
llvm-svn: 313389
|
|
|
|
|
|
|
|
| |
Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.
llvm-svn: 306948
|
|
|
|
|
|
|
| |
Summary:
The commit caused a documentation breakage.
llvm-svn: 306946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depends on https://reviews.llvm.org/D34867.
Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html
Reviewers: anemet, davidxl, hfinkel
Reviewed By: anemet
Subscribers: fhahn, cfe-commits
Differential Revision: https://reviews.llvm.org/D34868
llvm-svn: 306945
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Depends on https://reviews.llvm.org/D34864.
To unify Clang and LLVM's spelling of "diagnostic[s] hotness", use the
new "diagnostics hotness" spelling in LLVM, which was added in
https://reviews.llvm.org/D34864.
Reviewers: anemet, davidxl
Reviewed By: anemet
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34865
llvm-svn: 306862
|
|
|
|
| |
llvm-svn: 302854
|
|
|
|
|
|
|
|
| |
distinct kind of input.
No functionality change intended.
llvm-svn: 301442
|
|
|
|
| |
llvm-svn: 297681
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30738
llvm-svn: 297649
|
|
|
|
|
|
| |
Updates for llvm r295465.
llvm-svn: 295466
|
|
|
|
|
|
|
|
|
|
|
| |
preprocessor macros.
Added "-fdebug-macro" flag (and "-fno-debug-macro" flag) to enable (and to disable) emitting macro debug info.
Added CC1 "-debug-info-macro" flag that enables emitting macro debug info.
Differential Revision: https://reviews.llvm.org/D16135
llvm-svn: 294637
|
|
|
|
|
|
|
|
| |
for the module containing the summary.
Differential Revision: https://reviews.llvm.org/D29067
llvm-svn: 293209
|
|
|
|
|
|
|
|
|
|
| |
The handler that deals with IR passed/missed/analysis remarks is extended to
also handle the corresponding MIR remarks.
The more thorough testing in done via llc (rL293113, rL293121). Here we just
make sure that the functionality is accessible through clang.
llvm-svn: 293146
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
modules.
Summary:
Now when you ask clang to link in a bitcode module, you can tell it to
set attributes on that module's functions to match what we would have
set if we'd emitted those functions ourselves.
This is particularly important for fast-math attributes in CUDA
compilations.
Each CUDA compilation links in libdevice, a bitcode library provided by
nvidia as part of the CUDA distribution. Without this patch, if we have
a user-function F that is compiled with -ffast-math that calls a
function G from libdevice, F will have the unsafe-fp-math=true (etc.)
attributes, but G will have no attributes.
Since F calls G, the inliner will merge G's attributes into F's. It
considers the lack of an unsafe-fp-math=true attribute on G to be
tantamount to unsafe-fp-math=false, so it "merges" these by setting
unsafe-fp-math=false on F.
This then continues up the call graph, until every function that
(transitively) calls something in libdevice gets unsafe-fp-math=false
set, thus disabling fastmath in almost all CUDA code.
Reviewers: echristo
Subscribers: hfinkel, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D28538
llvm-svn: 293097
|
|
|
|
| |
llvm-svn: 292972
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 291123
|
|
|
|
| |
llvm-svn: 288227
|
|
|
|
|
|
|
|
| |
Other AST consumers can deserialize interesting decls that we might
codegen, but they won't make it to the final object file and can trigger
assertions in debug information generation after finalization.
llvm-svn: 288221
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.
Reviewers: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26884
llvm-svn: 287449
|
|
|
|
|
|
| |
We have to specify a name and description for the timers and groups now.
llvm-svn: 287371
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26562
llvm-svn: 286752
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 286567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.
The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.
Differential Revision: https://reviews.llvm.org/D26384
llvm-svn: 286214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The backend now has the capability to save information from optimizations, the
same information that can be used to generate optimization diagnostics but in
machine-consumable form, into an output file. This can be enabled when using
opt (see r282539), and this change enables it when using clang. The idea is
that other tools will be able to consume these files, and perhaps in
combination with the original source code, produce various kinds of
optimization reports for users (and for compiler developers).
We now have at-least two tools that can consume these files:
* tools/llvm-opt-report
* utils/opt-viewer
Using the flag -fsave-optimization-record will cause the YAML file to be
generated; the file name will be based on the output file name (if we're using
-c or -S and have an output name), or the input file name. When we're using
CUDA, or some other offloading mechanism, separate files are generated for each
backend target. The output file name can be specified by the user using
-foptimization-record-file=filename.
Differential Revision: https://reviews.llvm.org/D25225
llvm-svn: 283834
|
|
|
|
| |
llvm-svn: 283004
|
|
|
|
|
|
|
| |
With the new streaming interface in LLVM, these class names need to be
typed a lot and it's way too looong.
llvm-svn: 282545
|
|
|
|
| |
llvm-svn: 282540
|
|
|
|
|
|
| |
This reverts commit r282500.
llvm-svn: 282504
|
|
|
|
| |
llvm-svn: 282500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Add -fdiagnostics-show-hotness
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281293
|
|
|
|
|
|
|
|
| |
This reverts commit r281276.
Many bots are failing.
llvm-svn: 281279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I've recently added the ability for optimization remarks to include the
hotness of the corresponding code region. This uses PGO and allows
filtering of the optimization remarks by relevance. The idea was first
discussed here:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334
The general goal is to produce a YAML file with the remarks. Then, an
external tool could dynamically filter these by hotness and perhaps by
other things.
That said it makes sense to also expose this at the more basic level
where we just include the hotness info with each optimization remark.
For example, in D22694, the clang flag was pretty useful to measure the
overhead of the additional analyses required to include hotness.
(Without the flag we don't even run the analyses.)
For the record, Hal has already expressed support for the idea of this
patch on IRC.
Differential Revision: https://reviews.llvm.org/D23284
llvm-svn: 281276
|
|
|
|
|
|
|
|
|
|
|
|
| |
This can happen when emitting a local decl, which triggers
loading a decl imported from an AST file, which we then
hand to the AST consumer. Timer is not allowed to recurse
so an assertion fire. Keep a reference counter to avoid this
problem. LGTM'd by Richard Smith on IRC.
Differential Revision: https://reviews.llvm.org/D20748
llvm-svn: 276242
|
|
|
|
|
|
|
|
|
|
| |
Summary: Removed unused headers, replaced some headers with forward class declarations
Patch by: Eugene <claprix@yandex.ru>
Differential Revision: https://reviews.llvm.org/D20100
llvm-svn: 275882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 275507
|
|
|
|
|
|
|
|
|
|
| |
For the new hotness attribute, the API will take the pass rather than
the pass name so we can no longer play the trick of AlwaysPrint being a
special pass name. This adds a getter to help the transition.
There is also a corresponding llvm patch.
llvm-svn: 274101
|
|
|
|
| |
llvm-svn: 273178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file. Using -fembed-bitcode-marker will only introduce a
marker in both sections.
Depends on D17390
Reviewers: rsmith
Subscribers: yaron.keren, vsk, cfe-commits
Differential Revision: http://reviews.llvm.org/D17392
llvm-svn: 269202
|
|
|
|
|
|
|
|
|
|
|
| |
note_fe_backend_invalid_loc expects three arguments (file, line, column),
and will assert when only given two. The other two places in this file that
use note_fe_backend_invalid_loc already supply the Column for the third
parameter.
http://reviews.llvm.org/D19936
llvm-svn: 268732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow-on to apply Duncan's new DIType ODR uniquing from
r266549 and r266713 in more places.
When invoking ThinLTO backend compiles via clang (for a distributed
build), invoke enableDebugTypeODRUniquing() before parsing the module.
Reviewers: dexonsmith, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D19264
llvm-svn: 266852
|
|
|
|
|
|
|
|
| |
Turns out it was there mostly to prevent Clang asking people to report a bug.
This time we report something to Clang's real diagnostics handler so that it
exits with something approximating a real error and tidies up after itself.
llvm-svn: 265592
|