-
Notifications
You must be signed in to change notification settings - Fork 111
Conversation
…stration. APICalls allows groups of functions to be composed into an API that can be registered as a unit with an RPC endpoint. Doing registration on a-whole API basis (rather than per-function) allows missing API functions to be detected early. APICalls also allows Function membership to be tested at compile-time. This allows clients to write static assertions that functions to be called are members of registered APIs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291380 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291381 91177308-0d34-0410-b5e6-96231b3b80d8
…zero masking for patterns that already use the aligned form. NFC git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291383 91177308-0d34-0410-b5e6-96231b3b80d8
XOP was prematurely matching, doubling the cost of ashr/lshr uniform shifts. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291390 91177308-0d34-0410-b5e6-96231b3b80d8
The 'fast' costs should only work for shifts by uniform constants (uniform non-constant are lowered using the slow default implementation). Logical shifts were not taking into account that we must mask the psrlw result, so the costs needed to be doubled. Added missing AVX2/AVX512BW costs as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291391 91177308-0d34-0410-b5e6-96231b3b80d8
I noticed this problem as part of the ongoing attempt to canonicalize min/max ops in IR. The debug output shows nodes like this: t4: i32 = xor t2, Constant:i32<-1> t21: i8 = setcc t4, Constant:i32<0>, setlt:ch t14: i32 = select t21, t4, Constant:i32<-1> And because the select is holding onto the t4 (xor) node while EmitTest creates a new x86-specific xor node, the lowering results in: t4: i32 = xor t2, Constant:i32<-1> t25: i32,i32 = X86ISD::XOR t2, Constant:i32<-1> t28: i32,glue = X86ISD::CMOV Constant:i32<-1>, t4, Constant:i8<15>, t25:1 Differential Revision: https://reviews.llvm.org/D28374 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291392 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291393 91177308-0d34-0410-b5e6-96231b3b80d8
Silences a warning from gcc:6. NFC git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291394 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291395 91177308-0d34-0410-b5e6-96231b3b80d8
Running a Debug build of objdump -objc-meta-data with a large Mach-O file is currently unnecessarily slow. With some local test input, this change reduces the run time from 75-85s down to 15-20s. The two changes are: Assert on pointer equality not array equality Replace vector<pair<address, symbol>> with DenseMap<address, symbol> Additionally, use a std::unique_ptr rather than handling the memory manually. Patch by Dave Lee! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291398 91177308-0d34-0410-b5e6-96231b3b80d8
…w result handlers, make abandonPendingResults public API. This should make installing asynchronous result handlers thread safe. The abandonPendingResults method is made public so that clients can disconnect from a remote even if they have asynchronous handlers awaing results from that remote. The asynchronous handlers will all receive "abandoned result" errors as their argument. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291399 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291400 91177308-0d34-0410-b5e6-96231b3b80d8
…esults test. This is preparation for improving a case with avx512dq. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291401 91177308-0d34-0410-b5e6-96231b3b80d8
…select of zeroes/ones when handling sign extends of i1 without VLX. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291402 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291404 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: By using stripPointerCasts we can get to the root value and then walk down the bitcast graph Reviewers: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28181 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291405 91177308-0d34-0410-b5e6-96231b3b80d8
…ws for empty string This is used in LDC for custom boolean commandline options, setArgStr is called with an empty string before using AddLiteralOption. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291406 91177308-0d34-0410-b5e6-96231b3b80d8
This patch moves convertToUnixPathSeparator from LLD to LLVM. Differential Revision: https://reviews.llvm.org/D28444 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291414 91177308-0d34-0410-b5e6-96231b3b80d8
… vselects of all ones and all zeros. Previously we emitted a VPTERNLOG and a separate masked move. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291415 91177308-0d34-0410-b5e6-96231b3b80d8
…moves. A future patch will conver it back to BLENDM if its beneficial to register allocation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291419 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291420 91177308-0d34-0410-b5e6-96231b3b80d8
not excluding ourselves when checking if any equivalent stores exist. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291421 91177308-0d34-0410-b5e6-96231b3b80d8
computeInterleaveCount() is not defined/used and is therefore removed. Review: Davide Italiano git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291423 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291424 91177308-0d34-0410-b5e6-96231b3b80d8
invalid. This fixes use-after-free bugs that will arise with any interesting use of SCEV. I've added a dedicated test that works diligently to trigger these kinds of bugs in the new pass manager and also checks for them explicitly as well as triggering ASan failures when things go squirly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291426 91177308-0d34-0410-b5e6-96231b3b80d8
This patch doesn't create thunk for branch operation when following conditions are met: - Architecture is AArch64 - Relocation target is in the same object file - Relocation target is close enough to be encoded in immediate offset In such case we branch directly to the target instead of branching to thunk Differential revision: https://reviews.llvm.org/D28108 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291431 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC does not like to reinterpret_cast to a uint64_t. Use a different cast instead. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291435 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291438 91177308-0d34-0410-b5e6-96231b3b80d8
…1486. Summary: Originally i64 = umax t8, Constant:i64<4> was expanded into i32,i32 = umax Constant:i32<0>, Constant:i32<0> i32,i32 = umax t7, Constant:i32<4> Now instead the two produced umax:es return i32 instead of i32, i32. Thanks to Jan Vesely for help with the test case. Patch by mikael.holmen at ericsson.com Reviewers: bogner, jvesely, tstellarAMD, arsenm Subscribers: test, wdng, RKSimon, arsenm, nhaehnle, llvm-commits Differential Revision: https://reviews.llvm.org/D28135 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291441 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291442 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292255 | mgorny | 2017-01-17 13:04:19 -0800 (Tue, 17 Jan 2017) | 12 lines [cmake] Update SOVERSION for the new versioning scheme Update SOVERSION to use just the major version number rather than major+minor, to match the new versioning scheme where only major is used to indicate API/ABI version. Since two-digit SOVERSIONs were introduced post 3.9 branching, this change does not risk any SOVERSION collisions. In the past, two-component X.Y SOVERSIONs were shortly used but those will not interfere with the new ones since the new versions start at 4. Differential Revision: https://reviews.llvm.org/D28730 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292270 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r291968 | dannyb | 2017-01-13 14:40:01 -0800 (Fri, 13 Jan 2017) | 23 lines NewGVN: Move leaders around properly to ensure we have a canonical dominating leader. Fixes PR 31613. Summary: This is a testcase where phi node cycling happens, and because we do not order the leaders by domination or anything similar, the leader keeps changing. Using std::set for the members is too expensive, and we actually don't need them sorted all the time, only at leader changes. We could keep both a set and a vector, and keep them mostly sorted and resort as necessary, or use a set and a fibheap, but all of this seems premature. After running some statistics, we are able to avoid the vast majority of sorting by keeping a "next leader" field. Most congruence classes only have leader changes once or twice during GVN. Reviewers: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28594 ------------------------------------------------------------------------ ------------------------------------------------------------------------ r291979 | dannyb | 2017-01-13 15:54:10 -0800 (Fri, 13 Jan 2017) | 1 line NewGVN: Fix PR31613 test regex naming ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292307 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r292133 | hfinkel | 2017-01-16 07:22:01 -0800 (Mon, 16 Jan 2017) | 10 lines Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith When transferring affected values in the cache from an old value, identified by the value of the current callback, to the specified new value we might need to insert a new entry into the DenseMap which constitutes the cache. Doing so might delete the current callback object. Move the copying logic into a new function, a member of the assumption cache itself, so that we don't run into UB should the callback handle itself be removed mid-copy. Differential Revision: https://reviews.llvm.org/D28749 ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292312 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------ r291966 | majnemer | 2017-01-13 14:24:27 -0800 (Fri, 13 Jan 2017) | 6 lines [LoopStrengthReduce] Don't bother rewriting PHIs in catchswitch blocks The catchswitch instruction cannot be split, don't bother trying to rewrite it. This fixes PR31627. ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_40@292340 91177308-0d34-0410-b5e6-96231b3b80d8
There are two failing JS
|
What might be going on in that test is LLVM may have renamed the intrinsic a little. In the test we used to have |
(All we do in CallHandlers for that method is return an empty string, which is the right thing for that intrinsic; otherwise, if no handler is found in that file, we emit a call to what we assume is something imported into asm/wasm, which is why it looks as it does in your output sample.) |
Dead code elimination would remove a bunch of math calls.
Invariant intrinsics are now suffixed with types.
That worked! I've fixed that test, looking into the other one now. |
I believe the second test is probably broken by D26594, where the behaviour of Here is the diff of emscripten master vs diff --git a/lib/Target/JSBackend/JSBackend.cpp b/lib/Target/JSBackend/JSBackend.cpp
index d959102..6ea52c7 100644
--- a/lib/Target/JSBackend/JSBackend.cpp
+++ b/lib/Target/JSBackend/JSBackend.cpp
@@ -270,7 +270,7 @@ namespace {
OptLevel(OptLevel), StackBumped(false), GlobalBasePadding(0), MaxGlobalAlign(0),
CurrInstruction(nullptr) {}
- const char *getPassName() const override { return "JavaScript backend"; }
+ StringRef getPassName() const override { return "JavaScript backend"; }
bool runOnModule(Module &M) override;
@@ -2658,14 +2658,14 @@ void JSWriter::generateExpression(const User *I, raw_string_ostream& Code) {
for (GetElementPtrInst::const_op_iterator E = GEP->op_end();
I != E; ++I) {
const Value *Index = *I;
- if (StructType *STy = dyn_cast<StructType>(*GTI++)) {
+ if (StructType *STy = GTI.getStructTypeOrNull()) {
// For a struct, add the member offset.
unsigned FieldNo = cast<ConstantInt>(Index)->getZExtValue();
uint32_t Offset = DL->getStructLayout(STy)->getElementOffset(FieldNo);
ConstantOffset = (uint32_t)ConstantOffset + Offset;
} else {
// For an array, add the element offset, explicitly scaled.
- uint32_t ElementSize = DL->getTypeAllocSize(*GTI);
+ uint32_t ElementSize = DL->getTypeAllocSize(GTI.getIndexedType());
if (const ConstantInt *CI = dyn_cast<ConstantInt>(Index)) {
// The index is constant. Add it to the accumulating offset.
ConstantOffset = (uint32_t)ConstantOffset + (uint32_t)CI->getSExtValue() * ElementSize;
@@ -4142,7 +4142,7 @@ Pass *createCheckTriplePass() {
bool JSTargetMachine::addPassesToEmitFile(
PassManagerBase &PM, raw_pwrite_stream &Out, CodeGenFileType FileType,
bool DisableVerify, AnalysisID StartBefore,
- AnalysisID StartAfter, AnalysisID StopAfter,
+ AnalysisID StartAfter, AnalysisID StopBefore, AnalysisID StopAfter,
MachineFunctionInitializer *MFInitializer) {
assert(FileType == TargetMachine::CGFT_AssemblyFile); The previous code was iterating through all type parameters, and then incrementing the iterator again inside the first condition. This is weird, and I can't really find the reason for it. When I change the code to When you look at the test itself, you'll see this: ; CHECK: function _getelementptr([[VAL_P:\$[a-z_]+]]) {
; CHECK: [[GEP:\$[a-z_]+]] = ((([[GEPINT:\$[a-z_]+]])) + 588|0);
define i32* @getelementptr([10 x [12 x i32] ]* %p) {
%t = getelementptr [10 x [12 x i32]], [10 x [12 x i32]]* %p, i32 1, i32 2, i32 3
ret i32* %t
} Comparing it to the output of |
Hmm, I don't understand that LLVM commit. I'd need to read more to get the context, I guess - seems like it's part of the big years-long GEP or pointer type changes, somehow? But regarding
It always increments GTI, since the ++ happens in the loop's first condition, which is always executed. It then enters either the first or the second condition. So each loop iteration increments once. You probably just need to increment GTI in the first condition. Perhaps less confusing would be to increment it before, saving the old value and using that. |
I debugged it a bit further and got it working by moving the incrementing of That test is now passing, I'm running the LLVM test suite locally, then I'll look at running the emscripten tests. |
I created And after that things look promising! 30 random tests pass. I'll run the full test suite next. |
Running the test suite overnight found a bunch of weird errors, that I tracked down to 63e73b3 . Not 100% sure about it, but seems to fix things. |
Ok, after that fix, I found a few small test changes that were necessary, pushed to the |
Ok, after a few more fixes across the repos, I think this merge is almost ready. I opened #166 and parallel PRs with your stuff + mine. As far as I can tell all tests pass there. Thanks @dylanmckay for all the work here! Much appreciated :) |
Thanks @dylanmckay and @kripken for working on this port! |
Superseded by #166 |
This is accompanied with emscripten-core/emscripten-fastcomp-clang#13