This repository has been archived by the owner on Feb 5, 2019. It is now read-only.
Update emscripten #130
Closed
Update emscripten #130
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove the acceptance of ANY_EXTEND nodes while trying to move and nodes back to loads. Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=35765 Differential Revision: https://reviews.llvm.org/D41625 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321641 91177308-0d34-0410-b5e6-96231b3b80d8
XLenVT in LowerFormalArguments is used only in an assert. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321642 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D41339 Patch by Shiva Chen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321643 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321644 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: isReg() in AArch64AsmParser.cpp is a bit of a misnomer, and would be better named 'isScalarReg()' instead. Patch [1/3] in a series to add operand constraint checks for SVE's predicated ADD/SUB. Reviewers: rengolin, mcrosier, evandro, fhahn, echristo Reviewed By: fhahn Subscribers: aemerson, javed.absar, llvm-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D41445 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321646 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewers: ruiu, davidxl, silvas, brzycki Reviewed By: brzycki Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41609 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321648 91177308-0d34-0410-b5e6-96231b3b80d8
…n r321204) Our internal testing has revealed has discovered bugs in PPC builds. I have forward reproduction instructions to the original author (Nirav). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321649 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321650 91177308-0d34-0410-b5e6-96231b3b80d8
…pdateAnalysisInformation Summary: We are incorrectly updating the LI when loop-simplify generates dedicated exit blocks for a loop. The issue is that there's an implicit assumption that the Preds passed into UpdateAnalysisInformation are reachable. However, this is not true and breaks LI by incorrectly updating the header of a loop. One such case is when we generate dedicated exits when the exit block is a landing pad (through SplitLandingPadPredecessors). There maybe other cases as well, since we do not guarantee that Preds passed in are reachable basic blocks. The added test case shows how loop-simplify breaks LI for the outer loop (and DT in turn) after we try to generate the LoopSimplifyForm. Reviewers: davide, chandlerc, sanjoy Reviewed By: davide Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41519 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321653 91177308-0d34-0410-b5e6-96231b3b80d8
Tests updated to explicitly use fast-isel at -O0 instead of implicitly. This change also allows an explicit -fast-isel option to override an implicitly enabled global-isel. Otherwise -fast-isel would have no effect at -O0. Differential Revision: https://reviews.llvm.org/D41362 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321655 91177308-0d34-0410-b5e6-96231b3b80d8
…sons (PR33325) This is an extension of D31156 with the goal that we'll allow memcmp() == 0 expansion for x86 to use 2 pairs of loads per block. The memcmp expansion pass (formerly part of CGP) will generate this kind of pattern with oversized integer compares, so we want to transform these into x86-specific vector nodes before legalization splits things into scalar chunks. See PR33325 for more details: https://bugs.llvm.org/show_bug.cgi?id=33325 Differential Revision: https://reviews.llvm.org/D41618 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321656 91177308-0d34-0410-b5e6-96231b3b80d8
Some systems still don't have this module which was introduced in version 2.0 (CentOS 7, sigh). Differential Revision: https://reviews.llvm.org/D41611 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321659 91177308-0d34-0410-b5e6-96231b3b80d8
A call may have an intrinsic name but not have a valid intrinsic ID, for example with llvm.invariant.group.barrier. If so, treat it as a normal call like FastISel does. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321662 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321668 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of solving PR35717: https://bugs.llvm.org/show_bug.cgi?id=35717 The larger IR optimization is proposed in D41603, but we can show the improvement in ValueTracking using codegen tests because SelectionDAG creates min/max nodes based on ValueTracking. Any target with min/max ops should show wins here. I chose AArch64 vector ops because they're clean and uniform. Some Alive proofs for the tests (can't put more than 2 tests in 1 page currently because the web app says it's too long): https://rise4fun.com/Alive/WRN https://rise4fun.com/Alive/iPm https://rise4fun.com/Alive/HmY https://rise4fun.com/Alive/CNm https://rise4fun.com/Alive/LYf git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321672 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321673 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D40524 Change-Id: Ie3a405b28503ceae999f5f3ba07a68fa733a2400 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321674 91177308-0d34-0410-b5e6-96231b3b80d8
I have no clue how this was missed when symbol table support was added. This change ensures that the visibility of symbols is preserved by default. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321681 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the code for handling G_SMULO didn't properly check for the signed multiply overflow, instead treating it the same as the unsigned G_UMULO. Fixes PR35800. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321690 91177308-0d34-0410-b5e6-96231b3b80d8
Currently it's not possible to access MCSubtargetInfo from a TgtMCAsmBackend. D20830 threaded an MCSubtargetInfo reference through MCAsmBackend::relaxInstruction, but this isn't the only function that would benefit from access. This patch removes the Triple and CPUString arguments from createMCAsmBackend and replaces them with MCSubtargetInfo. This patch just changes the interface without making any intentional functional changes. Once in, several cleanups are possible: * Get rid of the awkward MCSubtargetInfo handling in ARMAsmBackend * Support 16-bit instructions when valid in MipsAsmBackend::writeNopData * Get rid of the CPU string parsing in X86AsmBackend and just use a SubtargetFeature for HasNopl * Emit 16-bit nops in RISCVAsmBackend::writeNopData if the compressed instruction set extension is enabled (see D41221) This change initially exposed PR35686, which has since been resolved in r321026. Differential Revision: https://reviews.llvm.org/D41349 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321692 91177308-0d34-0410-b5e6-96231b3b80d8
TargetRegistryInfo::createMCAsmBackend no longer takes a TheTriple parameter. The majory of the TargetRegistryInfo::create* functions have no or very limitied per-parameter doc comments, and adding a comment for the MCSubtargetInfo, MCRegisterInfo and MCTargetOptions parameters seems like it would add no real value beyond reading the function signature. As such, I've just deleted the doc comment for TheTriple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321694 91177308-0d34-0410-b5e6-96231b3b80d8
As experimental backends, I didn't have them configured to build in my local build config. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321696 91177308-0d34-0410-b5e6-96231b3b80d8
… vectors. Summary: Add a register class for SVE predicate operands that can only be p0-p7 (as opposed to p0-p15) Patch [1/3] in a series to add predicated ADD/SUB instructions for SVE. Reviewers: rengolin, mcrosier, evandro, fhahn, echristo, olista01, SjoerdMeijer, javed.absar Reviewed By: fhahn Subscribers: aemerson, javed.absar, tschuett, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D41441 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321699 91177308-0d34-0410-b5e6-96231b3b80d8
This change deals with intrinsics with multiple outputs, for example load instrinsic with address updated. DAG selection for Instrinsics could be done either through source code or tablegen. Handling all intrinsics in source code would introduce a huge chunk of repetitive code if we have a large number of intrinsic that return multiple values (see NVPTX as an example). While intrinsic class in tablegen supports multiple outputs, tablegen only supports Intrinsics with zero or one output on TreePattern. This appears to be a simple bug in tablegen that is fixed by this change. For Intrinsics defined as: def int_xxx_load_addr_updated: Intrinsic<[llvm_i32_ty, llvm_ptr_ty], [llvm_ptr_ty, llvm_i32_ty], []>; Instruction will be defined as: def L32_X: Inst<(outs reg:$d1, reg:$d2), (ins reg:$s1, reg:$s2), "ld32_x $d1, $d2, $s2", [(set i32:$d1, i32:$d2, (int_xxx_load_addr_updated i32:$s1, i32:$s2))]>; Patch by Wenbo Sun, thanks! Differential Revision: https://reviews.llvm.org/D32888 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321704 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321706 91177308-0d34-0410-b5e6-96231b3b80d8
After D41349, we can now directly access MCSubtargetInfo from createARM*AsmBackend. This patch makes use of this, avoiding the need to create a fresh MCSubtargetInfo (which was previously always done with a blank CPU and feature string). Given the total size of the change remains pretty tiny and we're removing the old explicit destructor, I changed the STI field to a reference rather than a pointer. Differential Revision: https://reviews.llvm.org/D41693 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321707 91177308-0d34-0410-b5e6-96231b3b80d8
…log), log(exp) Summary: This patch enables folding following expressions under -ffast-math flag: exp(log(x)) -> x, exp2(log2(x)) -> x, log(exp(x)) -> x, log2(exp2(x)) -> x Reviewers: spatel, hfinkel, davide Reviewed By: spatel, hfinkel, davide Subscribers: scanon, llvm-commits Differential Revision: https://reviews.llvm.org/D41381 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321710 91177308-0d34-0410-b5e6-96231b3b80d8
Besides the unsightly print-out, it was causing some buildbots to fail, e.g. http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/9311 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321711 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@321713 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_60@321742 91177308-0d34-0410-b5e6-96231b3b80d8
…ightArithmeticByScalar, instead those were replaced by shiftRightByScalar, with the SIMD type Int32x4 vs Uint32x4 denoting whether the shift will be sign-extending or not.
fix_simd_right_shift
Bump version to 1.38.10, due to ABI changes.
fix_frem_for_precise_f32
Add a workaround for Safari 9 ARM iOS right shift by non-immediate zero JIT bug
We did not handle this properly before, without this option, we looked at the similarly-named function pointer emulation flag. Matched with emscripten-core/emscripten#7318
Leave that to the emcc driver to decide. See emscripten-core/emscripten#7319
I'm not sure when this broke or why its hasn't been picked up by CI.
|
Tested locally that llvm-emscripten now compiles on dist-i686-linux. My build later failed due to missing lld checkout, but that's a local issue... @alexcrichton Can you please add this as a branch on this repo? I was hoping that we could get away with just using upstream directly, but apparently it wasn't meant to be... |
|
Er oops I think I spent too long writing up this comment before realizing this was here. Should be available here now! -- https://github.com/rust-lang/llvm/tree/rust-emscripten-2018-11-09 |
This was referenced Mar 9, 2019
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is emscripten-fastcomp at v1.38.15 with an extra patch to fix the build on dist-i686-linux.
Running image locally to see if anything else needs to be patched...