llvm-svn: 367412

llvm-svn: 367411

These became needed after r367368.

llvm-svn: 367410

This was breaking /WX builds

llvm-svn: 367409

llvm-svn: 367408

The original documentation update was reviewed with D65330

llvm-svn: 367407

llvm-svn: 367406

llvm-svn: 367405

llvm-svn: 367404

Summary:
This adds the 'f' inline assembly constraint, as supported by GCC. An
'f'-constrained operand is passed in a floating point register. Exactly
which kind of floating-point register (32-bit or 64-bit) is decided
based on the operand type and the available standard extensions (-f and
-d, respectively).

This patch adds support in both the clang frontend, and LLVM itself.

Reviewers: asb, lewis-revill

Reviewed By: asb

Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 367403

Use a switch instead of many isa<> while checking for supported
values. Also be explicit about which cast instructions are supported;
This allows the removal of SIToFP from GenerateSignBits.

llvm-svn: 367402

This fixes some pipeline tests.
This reverts commit d0b6f429.

llvm-svn: 367401

llvm-svn: 367400

This adds support for parsing/emitting in IR the floating-point RISC-V
registers in inline assembly clobber lists.

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

llvm-svn: 367399

Summary:
* Loads and stores in SVE2 are gather/scatter not contiguous, fixed by
  renaming multiclasses to reflect this and also updated comments.
* Remove aliases from load/store multiclasses that reflect the behaviour
  of the original form.
* Fix bug in scatter store implementation, vector list should be used as
  input, not output.

Reviewed By: sdesmalen

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

llvm-svn: 367398

This adds the required extension to RISC-V's getRegForInlineAsmConstraint
in order to be able to correctly distringuish between the 32 and 64-bit
floating point registers when the generic fX name appears in inlineasm
clobber contraints. It also adds a check to validate that callee saved
floating point registers are only saved in this case when a hard-float
ABI is selected.

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

llvm-svn: 367397

Summary:
* Clarify comment with SVE2 for predicated shifts and move next to other
  shift instructions.
* Clarify comments for various instructions.
* Move FCVTX instruction next to other fp conversions.
* Move FLOGB to next to other fp instructions and fix description.
* Remove "cons" from non-constructive multiclass for bitwise shift-right
  and accumulate instructions.

Reviewed By: sdesmalen

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

llvm-svn: 367396

Add cmake to the list of packages required for compiling LLVM.
Also move make to the bottom of the list and mark it as optional.

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

llvm-svn: 367395

Summary:
This patch fixes a bug in the following instructions that should have been
implemented as destructive. A destructive instruction is an instruction where
one of the source registers also acts as the destination register. Therefore,
the contents of the source register, when the instruction begins execution, are
replaced by the result of the instruction when the instruction completes
execution [1]:

  * SRI/SLI
  * EORBT/EORTB
  * TBX
  * Narrowing top instructions
  * FP convert precision instructions

These changes are non-functional from the assembler/diassembler point-of-view
but are necessary for correct codegen.

[1] https://static.docs.arm.com/ddi0584/ae/DDI0584A_e_SVE_supp_armv8A.pdf

Reviewed By: sdesmalen

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

llvm-svn: 367394

Summary:
This patch introduces a type to straighten LLVM's alignment management.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html

The next step is to use this type throughout LLVM

Reviewers: jfb, jakehehrlich

Subscribers: mgorny, mgrang, dexonsmith, llvm-commits, courbet

Tags: #llvm

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

llvm-svn: 367393

Summary:
The last responsibility of the SymbolVendor was to hold an owning
reference to the object file (in case symbols are being read from a
different file than the main module). As SymbolFile classes already hold
a non-owning reference to the object file, we can easily remove this
responsibility of the SymbolVendor by making the SymbolFile reference
owning.

Reviewers: JDevlieghere, clayborg, jingham

Subscribers: lldb-commits

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

llvm-svn: 367392

This error was never tested. In this patch I improved
the error message, added the test case and also simplified
the code that processes a similar error right below.

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

llvm-svn: 367391

Run across a whole function, visiting each basic block one at a time.

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

llvm-svn: 367389

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