Under -enable-unsafe-fp-math, SELECT_CC lowering in AArch64
transforms floating point comparisons of the form "a == 0.0 ? 0.0 : x" to
"a == 0.0 ? a : x". But it incorrectly assumes that 'x' and 'a' have
the same type which can lead to a wrong CSEL node that crashes later
due to nonsensical copies.
Differential Revision: https://reviews.llvm.org/D26394
llvm-svn: 286231
-Start using argparse instead of mimicking CLI parsing.
-PEPify the code.
-Decrease the number of imports by slightly cleaning up the script.
Reviewers: alexfh
Differential Revision: https://reviews.llvm.org/D25074
llvm-svn: 286228
This additional information can be used to improve the locations when generating remarks for loops.
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25763
llvm-svn: 286227
Summary:
This provides a better interface for clang-tidy and encapsulates the knowledge
about experimental checkers instead of leaving this to the clients.
Reviewers: zaks.anna
Subscribers: a.sidorin, NoQ, dcoughlin, cfe-commits
Differential Revision: https://reviews.llvm.org/D26310
llvm-svn: 286218
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
Summary:
If a file has been renamed/deleted from the filesystem and --diff mode
with two commits is active, attempting to get the file's mode will fail.
This change uses git-ls-tree instead to get the correct permissions for
the given revision.
Patch by Luis Hector Chavez!
Reviewers: djasper, lodato
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D26287
llvm-svn: 286212
Atomic stores terminate release sequences on the atomic variable,
and must use ReleaseStore primitive instead of Release.
This was broken in r192355 during a refactoring.
Restore correct behavior and add a test.
llvm-svn: 286211
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for clang's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
llvm-svn: 286210
When using LLVM_DISTRIBUTION_COMPONENTS, it's possible for LLVM's
export list to be empty. If this happens the install(EXPORTS) command
will fail, but since there isn't anything to install anyway we really
just want to skip it.
llvm-svn: 286209
As proposed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/106630.html
Move block info block state to a new class, BitstreamBlockInfo.
Clients may set the block info for a particular cursor with the
BitstreamCursor::setBlockInfo() method.
At this point BitstreamReader is not much more than a container for an
ArrayRef<uint8_t>, so remove it and replace all uses with direct uses
of memory buffers.
Differential Revision: https://reviews.llvm.org/D26259
llvm-svn: 286207
This makes the logic easier to follow and also propagates
StringRef up to the API boundary, which is necessary for
making higher up StringRef API changes.
Differential Revision: https://reviews.llvm.org/D26325
llvm-svn: 286204
Visual Studio 2013 and up have these functions, and we don't need to
support older versions.
There are some remaining _LIBCPP_MSVCRT exclusions which are present on
Visual Studio 2015 but not 2013. Those will be addressed in a follow-up.
Differential Revision: https://reviews.llvm.org/D26377
llvm-svn: 286202
asan_device_setup script is using LD_PRELOAD to inject the ASan
runtime library into the Zygote process. This breaks when the Zygote
or any of its descendants spawn a process with different bitness due
to the fact that the ASan-RT library name includes the target
architecture.
The fix is to preload the library through a symlink which has the
same name in lib and lib64.
llvm-svn: 286188
Summary:
This will prevent the check warning the variables which have been
implicitly added by compiler, like the following case (in for-range loop):
the variable '__end' is copy-constructed from a const reference...
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25911
llvm-svn: 286186
Summary:
Set _install_rpath to CMAKE_INSTALL_RPATH if it is defined, so that eventually
INSTALL_RPATH is set to CMAKE_INSTALL_RPATH.
The "if(NOT DEFINED CMAKE_INSTALL_RPATH)" was missing a corresponding else
clause.
This also cleans up the fix made in r285908.
Patch by Azharuddin Mohammed
Reviewers: john.brawn, sgundapa, beanz
Subscribers: chapuni, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D26289
llvm-svn: 286184
Self-referencing PHI nodes need their destination operands to be constrained
because nothing else is likely to do so. For now we just pick a register class
naively.
Patch mostly by Ahmed again.
llvm-svn: 286183
We need to apply the same export logic in clang as in llvm for
LLVM_DISTRIBUTION_COMPONENTS, or the clang exports will be invalid
when we use this config.
This makes using distribution components without setting
LLVM_TOOLCHAIN_ONLY=On work correctly.
llvm-svn: 286181
Codegen prepare sinks comparisons close to a user is we have only one register
for conditions. For AMDGPU we have many SGPRs capable to hold vector conditions.
Changed BE to report we have many condition registers. That way IR LICM pass
would hoist an invariant comparison out of a loop and codegen prepare will not
sink it.
With that done a condition is calculated in one block and used in another.
Current behavior is to store workitem's condition in a VGPR using v_cndmask
and then restore it with yet another v_cmp instruction from that v_cndmask's
result. To mitigate the issue a forward propagation of a v_cmp 64 bit result
to an user is implemented. Additional side effect of this is that we may
consume less VGPRs in a cost of more SGPRs in case if holding of multiple
conditions is needed, and that is a clear win in most cases.
llvm-svn: 286171
Rafael Espindola