llvm-svn: 367388

If we detect a built-in declaration for which we cannot derive a type
matching the pattern in the Builtins.def file, we currently emit a
warning that the respective header is needed. However, this is not
necessarily the behavior we want as it has no connection to the location
of the declaration (which can actually be in the header in question).
Instead, this warning is generated
  - if we could not build the type for the pattern on file (for some
    reason). Here we should make the reason explicit. The actual problem
    is otherwise circumvented as the warning is misleading, see [0] for
    an example.
  - if we could not build the type for the pattern because we do not
    have a type on record, possible since D55483, we should not emit any
    warning. See [1] for a legitimate problem.

This patch address both cases. For the "setjmp" family a new warning is
introduced and for built-ins without type on record, so far
"pthread_create", we do not emit the warning anymore.

Also see: PR40692

[0] https://lkml.org/lkml/2019/1/11/718
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583

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

llvm-svn: 367387

Bitwise-or with a non-zero constant will always evaluate to true.  Switch to
bitwise-and which will only evalute to true if the specified bit is set in the
other operand.

llvm-svn: 367386

Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.

llvm-svn: 367385

When investigating a completion bug I got confused by the API.
LongestCommonPrefix finds the longest common prefix of the strings in
the string list. Instead of returning that string through an output
argument, just return it by value.

llvm-svn: 367384

Summary: The minimum compilers support all have alignas, and we don't use LLVM_ALIGNAS anywhere anymore. This also removes an MSVC diagnostic which, according to the comment above, isn't relevant anymore.

Reviewers: rnk

Subscribers: mgorny, jkorous, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 367383

In PowerPC, there is instruction to load vector in big endian element order when it's in little endian target. 
So we can combine vector load + reverse into big endian load to eliminate the swap instruction.
Also combine vector reverse + store into big endian store.

llvm-svn: 367382

We had couple places which still return 10 as a maximum
occupancy. Fixed.

Also print comment about occupancy as compiler see it.

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

llvm-svn: 367381

When a line fails to match the stackframe regex we now report
it in the log.

rdar://problem/49476995

llvm-svn: 367380

This option disables the validation of binary UUIDs. This is useful
in environments where the `otool` binary is not available.

rdar://problem/49476995

llvm-svn: 367379

rdar://problem/49476995

llvm-svn: 367378

Instead of polluting the LLDBTableGenBackends header with helpers used
by both emitters, move them into a separate files.

llvm-svn: 367377

It has bothered me for a while that these guard against cases that
should never happene, so replace these with asserts.

llvm-svn: 367376

Fixes "no member named 'vector' in namespace 'std'" compile error.

llvm-svn: 367375

Summary: This emits labels around heapallocsite calls in SelectionDAG.

Reviewers: rnk

Subscribers: MatzeB, aprantl, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367374

AMDGPU uses some custom code predicates for testing alignments.

I'm still having trouble comprehending the behavior of predicate bits
in the PatFrag hierarchy. Any attempt to abstract these properties
unexpectdly fails to apply them.

llvm-svn: 367373

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two modes:

1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.

The format contains:

* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)

A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.

On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.

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

Original llvm-svn: 367364
Revert llvm-svn: 367370

llvm-svn: 367372

The reordering of the UID field makes the size of a
FileEntry 8 bytes smaller on 64bit platforms.

llvm-svn: 367371

This reverts commit r367364.

Breaks some bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-gn/builds/3161/steps/annotate/logs/stdio

llvm-svn: 367370

llvm-svn: 367369

SymbolFilePDB tests were using GetTypeSystemForLanguage but weren't
changed to accomodate the use of an llvm::Expected. I adjusted them
accordingly.

llvm-svn: 367368

We were previously just using a specialization in the class template instead of
creating a new specialization in the class instantiation.

Fixes llvm.org/PR42779.

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

llvm-svn: 367367

llvm-svn: 367366

Add an option to control whether or not to enable store merging in dag combiner
so we can workaround some bugs more easily.

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

llvm-svn: 367365

Add a new serializer, using a binary format based on the LLVM bitstream
format.

This format provides a way to serialize the remarks in two modes:

1) Separate mode: the metadata is separate from the remark entries.
2) Standalone mode: the metadata and the remark entries are in the same
file.

The format contains:

* a meta block: container version, container type, string table,
external file path, remark version
* a remark block: type, remark name, pass name, function name, debug
file, debug line, debug column, hotness, arguments (key, value, debug
file, debug line, debug column)

A string table is required for this format, which will be dumped in the
meta block to be consumed before parsing the remark blocks.

On clang itself, we noticed a size reduction of 13.4x compared to YAML,
and a compile-time reduction of between 1.7% and 3.5% on CTMark.

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

llvm-svn: 367364

This moves the std::map typedef into the header so it can be reused by
all the emitter implementations.

llvm-svn: 367363

Our minimum Visual C++ version is 19.10 from Visual Studio 2017.

llvm-svn: 367362

llvm-svn: 367361

Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
  `llvm::Expected<TypeSystem *>` now. This means that the result of a call
  is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
  non-null pointer to a TypeSystem.

Reviewers: JDevlieghere, davide, compnerd

Subscribers: jdoerfert, lldb-commits

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

llvm-svn: 367360

llvm-svn: 367359

As of svn rL367298, SymbolFileDWARF locks the module in many cases where
it needs to parse some aspect of the DWARF symbol file.
SymbolFileDWARF::ParseLineTable needs to lock the module because
SymbolVendor::ParseLineTable no longer locks it.

llvm-svn: 367358

The code is matching sext not zext.

llvm-svn: 367357

Summary: This fixes cross-builds with MinGW from case-sensitive file-systems (on Linux)

This is a cherry-pick from
https://github.com/google/benchmark/pull/840
https://github.com/google/benchmark/commit/8e48105d465c586068dd8e248fe75a8971c6ba3a

Original patch by: @jschueller (Julien Schueller) !

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

llvm-svn: 367356

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

llvm-svn: 367355

llvm-svn: 367354

This reverts commit d2254dbf.
This (unintentionally?) changed behavior, disallowing e.g. -x objective-c++-header

llvm-svn: 367353

Summary:
LoopRotate may simplify instructions, leading to the new instructions not having memory accesses created for them.
Allow this behavior, by allowing the new access to be null when the template is null, and looking upwards for the proper defined access when dealing with simplified instructions.

Reviewers: george.burgess.iv

Subscribers: jlebar, Prazek, llvm-commits

Tags: #llvm

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

llvm-svn: 367352

UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently
FAILs on Solaris/x86_64:

  clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11'

AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only),
which is what this patch does, together with updating another testcase.

Tested on x86_64-pc-solaris2.11.

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

llvm-svn: 367351

The previous code detected conflicts through copy-pasta, this versions
uses a 'loop'.

llvm-svn: 367350

Summary:
- Use the passed `DL` directly as retrieving data layout from CS by
  checking the called function is not reliable. Under indirect function
  call, there is no called function.

Subscribers: jholewinski, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367349