WIP: Update to LLVM 5.0 #199
Conversation
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308162 91177308-0d34-0410-b5e6-96231b3b80d8
…tHostCPUName/getHostCPUFeatures for 32-bit builds too. We're already using it in 64-bit builds because 64-bit MSVC doesn't support inline assembly. As far as I know we were using inline assembly because at the time the code was added we had to support MSVC 2008 pre-SP1 while the intrinsic was added to MSVC in SP1. Now that we don't have to support that we should be able to just use the intrinsic. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308163 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308166 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308168 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308169 91177308-0d34-0410-b5e6-96231b3b80d8
Was preventing rotate matching git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308171 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The current yaml::Input constructor takes a StringRef of data as its first parameter, discarding any filename information that may have been present when a YAML file was opened. Add an alterate yaml::Input constructor that takes a MemoryBufferRef, which can have a filename associated with it. This leads to clearer diagnostic messages. Sponsored By: DARPA, AFRL Reviewed By: arphaman Differential Revision: https://reviews.llvm.org/D35398 Patch by: Jonathan Anderson (trombonehero) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308172 91177308-0d34-0410-b5e6-96231b3b80d8
Convert iteration over operands to range-loop. Reviewed by: @rovka, @echristo Differential Revision: https://reviews.llvm.org/D35419 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308173 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308175 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for lowering to ISD::ROTL/ISD::ROTR, including rotate by immediate Differential Revision: https://reviews.llvm.org/D35463 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308177 91177308-0d34-0410-b5e6-96231b3b80d8
…orted for VOP3 instructions Summary: Previously, CodeGen checked first src operand type to determine if omod is supported by instruction. This isn't correct for some instructions: e.g. V_CMP_EQ_F32 has floating-point src operands but desn't support omod. Changed .td files to check if dst operand instead of src operand. Reviewers: arsenm, vpykhtin Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye Differential Revision: https://reviews.llvm.org/D35350 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308179 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308180 91177308-0d34-0410-b5e6-96231b3b80d8
Prevent store merge from merging stores into an invalid 128-bit store (realized as a f128 value in the context of the noimplicitfloat attribute). Previously, such stores are immediately split back into valid stores. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308184 91177308-0d34-0410-b5e6-96231b3b80d8
The target-independent lowering works fine, except concatenating 32-bit words. Add a pattern to generate A2_combinew instead of 64-bit asl/or. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308186 91177308-0d34-0410-b5e6-96231b3b80d8
Reviewers: t.p.northover, oren_ben_simhon, niravd, mcrosier Reviewed By: oren_ben_simhon, mcrosier Subscribers: nhaehnle, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D35466 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308193 91177308-0d34-0410-b5e6-96231b3b80d8
This patch series adds support for the IBM z14 processor. This part includes: - Basic support for the new processor and its features. - Support for new instructions (except vector 32-bit float and 128-bit float). - CodeGen for new instructions, including new LLVM intrinsics. - Scheduler description for the new processor. - Detection of z14 as host processor. Support for the new 32-bit vector float and 128-bit vector float instructions is provided by separate patches. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308194 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the new 32-bit vector float instructions of z14. This includes: - Enabling the instructions for the assembler/disassembler. - CodeGen for the instructions, including new LLVM intrinsics. - Scheduler description support for the instructions. - Update to the vector cost function calculations. In general, CodeGen support for the new v4f32 instructions closely matches support for the existing v2f64 instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308195 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the new 128-bit vector float instructions of z14. Note that these instructions actually only operate on the f128 type, since only each 128-bit vector register can hold only one 128-bit float value. However, this is still preferable to the legacy 128-bit float instructions, since those operate on pairs of floating-point registers (so we can hold at most 8 values in registers), while the new instructions use single vector registers (so we hold up to 32 value in registers). Adding support includes: - Enabling the instructions for the assembler/disassembler. - CodeGen for the instructions. This includes allocating the f128 type now to the VR128BitRegClass instead of FP128BitRegClass. - Scheduler description support for the instructions. Note that for a small number of operations, we have no new vector instructions (like integer <-> 128-bit float conversions), and so we use the legacy instruction and then reformat the operand (i.e. copy between a pair of floating-point registers and a vector register). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308196 91177308-0d34-0410-b5e6-96231b3b80d8
This allows to pass the build directory where all the opt.yaml files are rather than find | xargs which may invoke opt-viewer multiple times producing incomplete html output. The patch generalizes the same functionality from opt-diff. Differential Revision: https://reviews.llvm.org/D35491 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308200 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 546e006a023cccd0fd32afd442ab992d3515d4b8. Reverting until I can figure out llvm-symbolizer breakages on mac os. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308202 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by Dave Blaikie in review on r307952. Thanks Dave! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308203 91177308-0d34-0410-b5e6-96231b3b80d8
…function copy to import"" This reverts commit r308114 (and follow on fixes to test). There is a linking failure in a ThinLTO bot: http://green.lab.llvm.org/green/job/clang-stage2-configure-Rthinlto_build/3663/ (and undefined reference). It seems like it must be a second order effect of the heuristic change I made, and may take some time to try to reproduce locally and track down. Therefore, reverting for now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308206 91177308-0d34-0410-b5e6-96231b3b80d8
Rename the enum value from X86_64_Win64 to plain Win64. The symbol exposed in the textual IR is changed from 'x86_64_win64cc' to 'win64cc', but the numeric value is kept, keeping support for old bitcode. Differential Revision: https://reviews.llvm.org/D34474 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308208 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308211 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Instead of wiring these through the CVTypeVisitor interface, clients should inspect the CVTypeArray before visiting it and potentially load up the type server's TPI stream if they need it. No tests relied on this functionality because LLD was the only client. Reviewers: ruiu Subscribers: mgorny, hiraditya, zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D35394 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308212 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This didn't do much to speed things up, but it implements a FIXME, and I think it's a nice simplification. We don't need the record kind switch. We're doing that ourselves. Reviewers: ruiu, inglorion Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D35496 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308213 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308223 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is the first patch towards creating the llvm-mt tool for merging Windows manifests. This is a reimplementation of mt.exe. Reviewers: zturner, ruiu, rnk Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D35333 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308224 91177308-0d34-0410-b5e6-96231b3b80d8
This wasn't necessary before since they are always enabled for kernels, but this is necessary if they need to be forwarded to a callable function. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308226 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308227 91177308-0d34-0410-b5e6-96231b3b80d8
This changed in upstream commit r304758.
We must now explictly dereference many iterators rather than relying on the compiler coercing the iterator to its inner type automatically.
There is now a varargs version of this method, and passing the C 'NULL' value causes a compilation error because it is actually an integer.
The address space constructor argument was added in r299888.
These changes were made upstream in r303654.
The interface was changed quite a bit in r307722.
… using getArgumentList This method was removed in favour of querying the function directly for iterators.
…ator The destructor has been made private in r303362 in favor of calling Value::deleteValue.
These hooks have gained many new parameters since 4.0.1.
…0 to LLVM 4.0.1 API. In particular, see commit bdbe828 "Add address space mangling to lifetime intrinsics"
dylanmckay
force-pushed
the
update-llvm-5.0
branch
from
e5ed0b7
to
b44bb44
Compare
|
Have pushed a new version of the branch, while also cherry-picking two relevant commits from This now successfully compiles again. |
|
So far as actual changes go, the thing to review the most would be the AttributeList API changes. The API changed very drastically. Previously there would be an Rather than simply port the bare-minimum of the API over (which would be extremely ugly), I refactored a lot of the attribute handling so that it works much cleaner with the current API. This shaves off some boilerplate and makes the code much harder to follow, but the previous attribute handling code was very dense in places, and my refactoring may accidentally subtly change behaviour. |
|
Oh, great work with this! For reference, I started a LLVM 4.0.1 merge some time ago, but have not been able to finish that one. The LLVM 4.0.1 merge is at: Reading your comments about API changes, I think some of the changes were resolved already above, so that might help some. It would be greatly preferred to first merge to LLVM 4.0.1 and only after that merge to LLVM 5.0, because that would give a good data point for developers to bisect against if something breaks upstream. We would like to tag one Emscripten version at least with 4.0.1 before 5.0 version, so that would help catch any potential regressions. |
|
I agree it would be preferable to do 4.0.1 and then 5.0 in two separate merges. However, if it's faster to go straight to 5.0, then given the importance of progress here and the lack of resources, I think that's an option too. |
|
Just as a heads up: this is becoming an increasingly urgent blocker for Rust, which supports Emscripten and is hence stuck at an older version of LLVM. Is there anything we on the Rust side can do to help this along? |
|
I think we are close to merging 4.0.1, after which we can focus on 5.0. The last blocker is #202 which we just diagnosed (see last comment there). Help would be welcome. In particular that issue just mentioned as diagnosed has something to do with LLVM function attributes; someone familiar with those might see the problem much faster than us. |
|
I was able to resolve that last remaining issue, so we should be good with merging to LLVM 4.0.1. |
|
Thank you @juj! |
|
Hey @dylanmckay, @aturon: I wonder if you would be able, or would know someone who might be able to review one odd change that was needed for the LLVM 4.0.1 merge branch, here:
This somehow relates to the However the peculiar situation here is that there are a number of other similar kind of code sites in the repository that have same kind of code pattern, and it looks like those do not need to be changed. I am trying to understand why this specific commit above was needed, and what actually caused the off by one here after the LLVM 4.0 -> LLVM 4.0.1 merge update. Any help here would be appreciated! |
|
Looks like I was able to figure this out, it was the |
|
What's the progress for enabling LLVM 5 support in Emscripten? |
|
We just landed the merge to LLVM 4.0.1 release point this week. Merging to LLVM 5.0 can now proceed, although I wish that this work will take the new merged LLVM 4.0.1 release point as the base, so that there won't be double merges of commits between 4.0-4.0.1 (I think the original LLVM 5.0 merge started based on LLVM 4.0 code) |
|
I believe this PR can be closed, as an upgrade to LLVM 6.0.1 happened in the meantime. |
This pull request updates the fastcomp LLVM library to LLVM 5.0.
It is a merge of the llvm-project/llvm/branches/release_50 branch, although I've used the official LLVM git mirror as the remote.
LLVM 5.0.1 uses the 5.0 branch, and thus this PR also adds a few commits from 5.0.1. Once LLVM tags 5.0.1 in November, we will be free to update emscripten with the new commits.