llvm-svn: 286621

(1) Add support for function key negotiation.

The previous version of the RPC required both sides to maintain the same
enumeration for functions in the API. This means that any version skew between
the client and server would result in communication failure.

With this version of the patch functions (and serializable types) are defined
with string names, and the derived function signature strings are used to
negotiate the actual function keys (which are used for efficient call
serialization). This allows clients to connect to any server that supports a
superset of the API (based on the function signatures it supports).

(2) Add a callAsync primitive.

The callAsync primitive can be used to install a return value handler that will
run as soon as the RPC function's return value is sent back from the remote.

(3) Launch policies for RPC function handlers.

The new addHandler method, which installs handlers for RPC functions, takes two
arguments: (1) the handler itself, and (2) an optional "launch policy". When the
RPC function is called, the launch policy (if present) is invoked to actually
launch the handler. This allows the handler to be spawned on a background
thread, or added to a work list. If no launch policy is used, the handler is run
on the server thread itself. This should only be used for short-running
handlers, or entirely synchronous RPC APIs.

(4) Zero cost cross type serialization.

You can now define serialization from any type to a different "wire" type. For
example, this allows you to call an RPC function that's defined to take a
std::string while passing a StringRef argument. If a serializer from StringRef
to std::string has been defined for the channel type this will be used to
serialize the argument without having to construct a std::string instance.

This allows buffer reference types to be used as arguments to RPC calls without
requiring a copy of the buffer to be made.

llvm-svn: 286620

llvm-svn: 286619

llvm-svn: 286617

Summary:
Fix off-by-one indexing error in loop checking that inserted value was a
splat vector.

Add code to check that INSERT_VECTOR_ELT nodes constructing the splat
vector have the expected constant index values.

Reviewers: t.p.northover, jmolloy, mcrosier

Subscribers: aemerson, llvm-commits, rengolin

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

llvm-svn: 286616

They get called before initialization, which is a problem for winasan.

Test coming in compiler-rt.

llvm-svn: 286615

The current implementation is emitting a global constant that happens
to evaluate to the same bytes + relocation as a jump instruction on
X86. This does not work for PIE executables and shared libraries
though, because we end up with a wrong relocation type. And it has no
chance of working on ARM/AArch64 which use different relocation types
for jump instructions (R_ARM_JUMP24) that is never generated for
data.

This change replaces the constant with module-level inline assembly
followed by a hidden declaration of the jump table. Works fine for
ARM/AArch64, but has some drawbacks.
* Extra symbols are added to the static symbol table, which inflate
the size of the unstripped binary a little. Stripped binaries are not
affected. This happens because jump table declarations must be
external (because their body is in the inline asm).
* Original functions that were anonymous are now named
<original name>.cfi, and it affects symbolization sometimes. This is
necessary because the only user of these functions is the (inline
asm) jump table, so they had to be added to @llvm.used, which does
not allow unnamed functions.

llvm-svn: 286611

llvm-svn: 286610

This is a partial revert of r244615 (http://reviews.llvm.org/D11942),
which caused a major regression in debug info quality.

Turning the artificial __MergedGlobal symbols into private symbols
(l__MergedGlobal) means that the linker will not include them in the
symbol table of the final executable. Without a symbol table entry
dsymutil is not be able to process the debug info for any of the
merged globals and thus drops the debug info for all of them.

This patch is enabling the old behavior for all MachO targets while
leaving all other targets unaffected.

rdar://problem/29160481
https://reviews.llvm.org/D26531

llvm-svn: 286607

llvm-svn: 286606

llvm-svn: 286604

https://reviews.llvm.org/D26526

- Fixed DW_FORM_strp to be correctly sized and extracted for DWARF64
- Added some missing strp variants as well
- Fixed comment typo

llvm-svn: 286603

llvm-svn: 286601

Fix windows buildbot where warnings are errors. We had a switch statement where all enumerations were handled, but some compilers don't recognize this. Simplify the logic so that all compilers will know a return value is returned in all cases.

llvm-svn: 286600

Clean up DWARFFormValue by reducing duplicated code and removing DWARFFormValue::getFixedFormSizes()

In preparation for a follow on patch that improves DWARF parsing speed, clean up DWARFFormValue so that we have can get the fixed byte size of a form value given a DWARFUnit or given the version, address byte size and dwarf32/64.

This patch cleans up code so that everyone is using one of the new DWARFFormValue functions:

static Optional<uint8_t> DWARFFormValue::getFixedByteSize(dwarf::Form Form, const DWARFUnit *U = nullptr);
static Optional<uint8_t> DWARFFormValue::getFixedByteSize(dwarf::Form Form, uint16_t Version, uint8_t AddrSize, bool Dwarf32);

This patch changes DWARFFormValue::skipValue() to rely on the output of DWARFFormValue::getFixedByteSize(...) instead of duplicating the code in each function. This will reduce the number of changes we need to make to DWARF to fewer places in DWARFFormValue when we add support for new form.

This patch also starts to support DWARF64 so that we can get correct byte sizes for forms that vary according the DWARF 32/64.

To reduce the code duplication a new FormSizeHelper pure virtual class was created that can be created as a FormSizeHelperDWARFUnit when you have a DWARFUnit, or FormSizeHelperManual where you manually specify the DWARF version, address byte size and DWARF32/DWARF64. There is now a single implementation of a function that gets the fixed byte size (instead of two where one took a DWARFUnit and one took the DWARF version, address byte size and DWARFFormat enum) and one function to skip the form values.

https://reviews.llvm.org/D26526

llvm-svn: 286597

This patch corresponds to review:
https://reviews.llvm.org/D26307

Adds all the intrinsics used for various conversion builtins that will
be added to altivec.h. These are type conversions between various types of
vectors.

llvm-svn: 286596

llvm-svn: 286594

Pass -m elf_x86_64 to gold, as is done in other tests.

llvm-svn: 286593

This optimization merges adjacent zero stores into a wider store.

e.g.,

strh wzr, [x0]
strh wzr, [x0, #2]
; becomes
str wzr, [x0]

e.g.,

str wzr, [x0]
str wzr, [x0, #4]
; becomes
str xzr, [x0]

Previously, this was only enabled for Kryo and Cortex-A57.

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

llvm-svn: 286592

llvm-svn: 286591

This adds support for the compare logical and trap (memory)
instructions that were added as part of the miscellaneous
instruction extensions feature with zEC12.

llvm-svn: 286587

This adds support for the LZRF/LZRG/LLZRGF instructions that were
added on z13, and uses them for code generation were appropriate.

SystemZDAGToDAGISel::tryRISBGZero is updated again to prefer LLZRGF
over RISBG where both would be possible.

llvm-svn: 286586

This adds support for the 31-to-64-bit zero extension instructions
LLGT and LLGTR and uses them for code generation where appropriate.

Since this operation can also be performed via RISBG, we have to
update SystemZDAGToDAGISel::tryRISBGZero so that we prefer LLGT
over RISBG in case both are possible.  The patch includes some
simplification to the tryRISBGZero code; this is not intended
to cause any (further) functional change in codegen.

llvm-svn: 286585

llvm-svn: 286582

In preparation for demandedelts support

llvm-svn: 286579

llvm-svn: 286578

In preparation for demandedelts support

llvm-svn: 286577

llvm-svn: 286576

In preparation for demandedelts support

llvm-svn: 286575

Add GlobalISel skeleton, up to the point where we can select a ret void.

llvm-svn: 286573

In this case the index page is sorted by the source location.

llvm-svn: 286572

llvm-svn: 286571

I missed these files in examples/

llvm-svn: 286570

Add the new BitcodeWriter.h header, which was missed in my r286566
commit, and should fix all the bot failures.

llvm-svn: 286569

Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and BitcodeWriter.h.

This is to address Chandler's concern about sharing the same API header
between multiple libraries (BitReader and BitWriter). That concern is
why we create a single bitcode library in our downstream build of clang,
which led to r286297 being reverted as it added a dependency that
created a cycle only when there is a single bitcode library (not two as
in upstream).

Reviewers: mehdi_amini

Subscribers: dlj, mehdi_amini, llvm-commits

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

llvm-svn: 286566

Reviewers: anemet

Subscribers: fhahn

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

llvm-svn: 286564

llvm-svn: 286563

This would trigger an assertion at runtime otherwise.

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

llvm-svn: 286562

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

llvm-svn: 286561

This is need because of clang-tblgen

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

llvm-svn: 286560