llvm-svn: 344236

[tblgen][CodeGenSchedule] Add a check for invalid RegisterFile definitions with zero physical registers.

llvm-svn: 344235

Add a /showFilenames option for users who want clang to echo the
currently compiled filename. MSVC does this echoing by default, and it's
useful for showing progress in build systems that doesn't otherwise
provide any progress report, such as MSBuild.

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

llvm-svn: 344234

We assign indices sequentially for seen instructions, so we can just use
a vector and push back the seen instructions. No need for using a
DenseMap.

Reviewers: hsaito, rengolin, nadav, dcaballe

Reviewed By: rengolin

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

llvm-svn: 344233

We can avoid doing some unnecessary work by skipping debug instructions
in a few loops. It also helps to ensure debug instructions do not
prevent vectorization, although I do not have any concrete test cases
for that.

Reviewers: rengolin, hsaito, dcaballe, aprantl, vsk

Reviewed By: rengolin, dcaballe

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

llvm-svn: 344232

Summary:
This is compiler-rt part.
clang part is D50901.

Reviewers: rsmith, vsk, filcab, Sanitizers

Reviewed by: filcab

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

llvm-svn: 344231

Summary:
As per IRC disscussion, it seems we really want to have more fine-grained `-fsanitize=implicit-integer-truncation`:
* A check when both of the types are unsigned.
* Another check for the other cases (either one of the types is signed, or both of the types is signed).

This is clang part.
Compiler-rt part is D50902.

Reviewers: rsmith, vsk, Sanitizers

Reviewed by: rsmith

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

llvm-svn: 344230

Summary:
The goal of the patch in D49853 is to display counter on the line of function definition.
So some tests need to be fixed.

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: sylvestre.ledru, delcypher, llvm-commits, #sanitizers

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

llvm-svn: 344229

Summary:
Right now there is no hit counter on the line of function.
So the idea is add the line of the function to all the lines covered by the entry block.
Tests in compiler-rt/profile will be fixed in another patch: https://reviews.llvm.org/D49854

Reviewers: marco-c, davidxl

Reviewed By: marco-c

Subscribers: sylvestre.ledru, llvm-commits

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

llvm-svn: 344228

llvm-svn: 344227

This is https://bugs.llvm.org/show_bug.cgi?id=37538,

Currently, LLD may set both sh_link and sh_info for
.rela.plt section to zero when we have only .rela.iplt section part used.

ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)
says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table
and sh_info the "section to which the relocation applies."

When we set the sh_link field, for the regular case we use the .dynsym index.
For .rela.iplt sections, it is unclear what is the associated symbol table,
because R_*_RELATIVE relocations do not use symbol names and we might have no
.dynsym section at all so this patch uses .symtab section index.

Differential revision: https://reviews.llvm.org/D52830

llvm-svn: 344226

Without this, the code only compiled if the header was included after
something introduced the alias from `clang::` to `llvm::` for this type.
Any modules build would fail here.

llvm-svn: 344225

Summary:
As discussed in D48491, we can't really do this in the TableGen,
since we need to produce *two* instructions. This only implements
one single pattern. The other 3 patterns will be in follow-ups.

I'm not sure yet if we want to also fuse shift into here
(i.e `(x >> start) & ...`)

Reviewers: RKSimon, craig.topper, spatel

Reviewed By: craig.topper

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

llvm-svn: 344224

There is a transform that may replace `lshr (x+1), 1` with `lshr x, 1` in case
if it can prove that the result will be the same. However the initial instruction
might have an `exact` flag set, and it now should be dropped unless we prove
that it may hold. Incorrectly set `exact` attribute may then produce poison.

Differential Revision: https://reviews.llvm.org/D53061
Reviewed By: sanjoy

llvm-svn: 344223

libtool requires this text to be present, in order to conclude that
the tool supports response files. Also add an explicit test of using
response files with llvm-nm.

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

llvm-svn: 344222

llvm-svn: 344220

All uses of this option have been removed, and the intent is to change the purpose and default value of this option. To prevent it from having impacts on users, this patch temporarily removes the option and purges it from CMake caches. In a few days, once this has propagated to contributors I will re-introduce the option with the new default value.

llvm-svn: 344219

Previously adding header and table gen files was conditional on using an IDE. Since these files have the `HEADER_FILE_ONLY` attribute applied they are ignored as sources by all non-IDE generators, so there is really no reason not to include them.

Additionally having the CMake always include these files allows the CMake-server to include them in the sources list for targets, which is valuable to anyone using CMake-server integrated tools.

llvm-svn: 344218

Summary:
The script to generate code coverage reports supports passing filter paths to llvm-cov when generating the HTML reports, but doesn't pass those paths to the summary generation as well. This results in a summary report that doesn't match the HTML report.

This patch addresses the problem by also passing the filter paths to the summary report generation.

Reviewers: vsk

Subscribers: llvm-commits

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

llvm-svn: 344217

llvm::detail is not the only namespace named detail.  So if
someone has done a `using namespace llvm::support`, for example,
this will fail with an ambiguous namespace name.  Granted
people generally shouldn't be using large namespaces like that,
but it's common at local function scopes.

llvm-svn: 344216

llvm-svn: 344215

It was replaced with the better named
_LIBCPP_HAS_NO_BUILTIN_OVERLOADED_OPERATOR_NEW_DELETE.

llvm-svn: 344214

llvm-svn: 344213

llvm-svn: 344212

Summary: Instead of custom lowering to WebAssemblyISD nodes first.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 344211

llvm-svn: 344210

LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself.  llvm::Triple::BridgeOS 
isn't defined yet, so all references to that
are currently commented out.  

Also update Xcode project file to build the 
NativePDB etc plugins.

<rdar://problem/43353615> 

llvm-svn: 344209

llvm-svn: 344208

There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.

llvm-svn: 344207

Some targets use %progbits instead of @progbits.

Updating that check with a {{[@%]}}progbits regex to make those bots happy.

llvm-svn: 344206

Summary: Depends on D53007 and D53004.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, kristina, cfe-commits

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

llvm-svn: 344205

Summary:
Although the saturating float to int instructions are already
emitted from normal IR, the fpto{s,u}i instructions produce poison
values if the argument cannot fit in the result type. These intrinsics
are therefore necessary to get guaranteed defined saturating behavior.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 344204

llvm-svn: 344203

Add thin shims to C interface to provide access to DebugLoc info for
Instructions, GlobalVariables and Functions.  Patch by Josh Berdine!

llvm-svn: 344202

implemented for the new pass manager so far.

llvm-svn: 344201

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

This is the LLVM side of Clang r344199.

Reviewers: davidxl, tejohnson, dlj, erik.pilkington

Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits

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

llvm-svn: 344200

This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

llvm-svn: 344199

Given a library call that is represented as an llvm intrinsic call, but
later transformed to an actual call, if an overriding definition of that
library routine is provided indirectly via an alias, prevent LTO from
eliminating the definition.

This is a fix for PR38547.

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

llvm-svn: 344198

Summary:
Global variables might declare themselves to be in explicit sections.
Calculate the entity size always to prevent assembler warnings
"entity size for SHF_MERGE not specified" when sections are to be
marked merge-able.

Fixes PR31828.

Reviewers: rnk, echristo

Reviewed By: rnk

Subscribers: llvm-commits, pirama, srhines

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

llvm-svn: 344197

llvm-svn: 344196