[CodeGen] [CUDA] Add the ability set default attrs on functions in linked modules.

Summary:
Now when you ask clang to link in a bitcode module, you can tell it to
set attributes on that module's fun

[CodeGen] [CUDA] Add the ability set default attrs on functions in linked 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

show more ...

IRGen: Factor out function CodeGenAction::loadModule. NFCI.

llvm-svn: 292972

CodeGen: plumb header search down to the IAS

inline assembly may use the `.include` directive to include other
content into the file. Without the integrated assembler, the `-I` group
gets passed to

CodeGen: plumb header search down to the IAS

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

show more ...

Fix -Winconsistent-missing-override in CodeGenAction.cpp

llvm-svn: 288227

Stop handling interesting deserialized decls after HandleTranslationUnit

Other AST consumers can deserialize interesting decls that we might
codegen, but they won't make it to the final object file

Stop handling interesting deserialized decls after HandleTranslationUnit

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

show more ...

Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)

Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.

Revie

Change setDiagnosticsOutputFile to take a unique_ptr from a raw pointer (NFC)

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

show more ...

Adapt to llvm NamedRegionTimer changes

We have to specify a name and description for the timers and groups now.

llvm-svn: 287371

Bitcode: Change module reader functions to return an llvm::Expected.

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

llvm-svn: 286752

Mirror the llvm changes that split Bitcode/ReaderWriter.h

The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
an

Mirror the llvm changes that split Bitcode/ReaderWriter.h

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

show more ...

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as th

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

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

show more ...

Add an option to save the backend-produced YAML optimization record to a file

The backend now has the capability to save information from optimizations, the
same information that can be used to gene

Add an option to save the backend-produced YAML optimization record to a file

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

show more ...

Use StringRef in Pass/PassManager APIs (NFC)

llvm-svn: 283004

Shorten DiagnosticInfoOptimizationRemark* to OptimizationRemark*. NFC

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

Adapt to LLVM optimization remark interface change. NFC

llvm-svn: 282540

Revert "Adapt to LLVM optimization remark interface change. NFC"

This reverts commit r282500.

llvm-svn: 282504

Adapt to LLVM optimization remark interface change. NFC

llvm-svn: 282500

Reapply r281276 with passing -emit-llvm in one of the tests

Original commit message:

Add -fdiagnostics-show-hotness

Summary:
I've recently added the ability for optimization remarks to include the

Reapply r281276 with passing -emit-llvm in one of the tests

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

show more ...

Revert "Add -fdiagnostics-show-hotness"

This reverts commit r281276.

Many bots are failing.

llvm-svn: 281279

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 o

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: 281276

show more ...

[CodeGen] Handle recursion in LLVMIRGeneration Timer.

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

[CodeGen] Handle recursion in LLVMIRGeneration Timer.

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

show more ...

[NFC] Header cleanup

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

Patch by: Eugene <claprix@yandex.ru>

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

[NFC] Header cleanup

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

show more ...

Frontend: Simplify ownership model for clang's output streams.

This changes the CompilerInstance::createOutputFile function to return
a std::unique_ptr<llvm::raw_ostream>, rather than an llvm::raw_o

Frontend: Simplify ownership model for clang's output streams.

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

show more ...

[Diag] Add getter shouldAlwaysPrint. NFC

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 na

[Diag] Add getter shouldAlwaysPrint. NFC

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

show more ...

Update for DiagnosticInfoStackSize changes

llvm-svn: 273178

Embed bitcode in object file (clang cc1 part)

Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandli

Embed bitcode in object file (clang cc1 part)

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

show more ...