Removed some redundancy.

Uploaded the correct patch

Changed predicate for variants with suffixes

Abandoned in favor of:
https://reviews.llvm.org/rG1ab3fe8a7a6537f882bbb2dac72c479d05eb8c49 and
https://reviews.llvm.org/rGf814dcbafbabd46a1babaeabec6acc3b70951bf4

Shouldn't the type change be guarded with a conditional compilation construct? I could write

std::list<int> l
assert(typeid(void) == typeid(l.unique()));

and expect this assertion to pass when compiling with, say, -std=c++98.

We have a similar problem with our port of libc++ and we also had to conditionalize all uses of long double downstream. Here is a list of files that we had to change: https://pastebin.com/5tTcSYxW
As you see, most of them are tests.
Another problem with long double is that it is used in a couple of places not strictly requiring it (include/locale, include/__mutex_base and include/thread), in those cases we introduced a _LIBCPP_LONGEST_DOUBLE macro which is defined to either double or long double depending on the availability of the latter.

Fix a comment

Subsumed by: https://reviews.llvm.org/D63838

LGTM

Added a test which uses <2 x double>. Alignment issue should be fixed separately, IMHO.

We maintain such library for an embedded toolchain. Besides, only C++17 and later versions are based on C11.

__libcpp_condvar_timedwait needs to be implemented in a different TU, so it can't be a template and at the same time it needs some sort of time point. I think timespec was chosen because it is what pthread_cond_timedwait expects. Do you think a specialization of chrono::time_point (like chrono::time_point<chrono::system_clock, chrono::nanoseconds> used by condition_variable::__do_timed_wait) would make more sense here?

In D63437#1546312, @ostannard wrote:

This doesn't look like the right pace to fix this - the backend can handle vectors of i8 and i16, which are also not legal types, so why can't it correctly handle vectors of f16?

• Rebase
• Avoid TableGen logic in instruction operands and constraints

• Fixed naming inconsistencies
• Removed comments about undefined instructions
• Factored out common parts of:
  • VMINV and VMAXV
  • VMINNMV and VMAXNMV
  • VMLADAV and VMLSDAV
  • VMLALDAV, VMLSLDAV (includes VRMLSLDAVH) and VRMLALDAVH
• Fixed inputs and constraints of non-accumulating instructions
• Split the assembler test into integer and floating point parts

Fixed the tablegen file and tests according to reviewer's comments. Added missing cases to ARMRegisterBankInfo.cpp

In D62651#1525589, @efriedma wrote:

LGTM

We could possibly use a custom inserter to generate the vins sequence, but it would probably involve some benchmarking to make sure there aren't any unexpected performance penalties due to the weird register usage. So I'm happy to put that off for now.

(On a side-note, I think you can insert a float into element zero of a vector with two vext instructions, which is the same number of instructions, but maybe lower latency.)