Mon, Jul 22
Fri, Jul 19
Removed some redundancy.
Tue, Jul 16
Wed, Jul 10
Tue, Jul 9
Uploaded the correct patch
Changed predicate for variants with suffixes
Mon, Jul 8
Fri, Jul 5
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.
Thu, Jul 4
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.
Mon, Jul 1
Fix a comment
Thu, Jun 27
Subsumed by: https://reviews.llvm.org/D63838
Wed, Jun 26
Added a test which uses <2 x double>. Alignment issue should be fixed separately, IMHO.
Tue, Jun 25
Jun 21 2019
Jun 19 2019
We maintain such library for an embedded toolchain. Besides, only C++17 and later versions are based on C11.
Jun 18 2019
__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?
Jun 17 2019
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?
Jun 14 2019
Jun 13 2019
- Avoid TableGen logic in instruction operands and constraints
Jun 12 2019
- 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
Jun 11 2019
Fixed the tablegen file and tests according to reviewer's comments. Added missing cases to ARMRegisterBankInfo.cpp
Jun 7 2019
Jun 4 2019
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.)
May 31 2019
Changed extraction patterns to avoid using GPRs as intermediate registers.
May 30 2019
May 10 2019
This caused https://bugs.llvm.org/show_bug.cgi?id=41835