- User Since
- Mar 9 2018, 11:57 AM (121 w, 2 d)
Fri, Jul 3
@sbc100 any suggestion for which test would be best to add a 64-bit version of? Most important thing is to ensure LLD is outputting 64-bit memory limits
Thu, Jul 2
Not much happening here, other than updating the memory limits writing. Probably needs an LLD specific test, @sbc100 ?
Removed unused init/drop intrinsics instead of trying to make them work for wasm64.
Also testing bulk-memory-encoding.s
Mon, Jun 29
@tlively I have no idea if my changes in IntrinsicsWebAssembly.td make sense, they merely pass the tests ;) please advise.
Thu, Jun 25
types & variables in InputChunks.cpp
- Fixed ISEL for FrameIndex
- Fixed 64-bit conditions in branches (thanks @aheejin!)
- Made the FrameIndex generation code in WebAssemblyRegisterInfo work.
- Made userstack.ll and stack-alignment.ll pass in wasm64.
- Code review fixes.
Mon, Jun 22
@dschuff still working on it, it uncovered some issues (as it should :)
I'll likely fork userstack.ll since the majority of lines need changes.
Thu, Jun 18
This is a first iteration, probably needs more tests :) I was thinking of forking userstack.ll since it has most __stack_pointer tests, but I am not sure if it's that useful. Needs a test that uses the new wasm-ld flag. Opinions welcome.
Mon, Jun 15
Made dedicated supportsWasm64/resolveWasm64 rather than sharing the Wasm32 versions.
Rebased against previous commit
Thanks for the tips. Though frankly in this case I should have tried to make this commit independent, since significant changes in the other one made rebasing a mess.
Fri, Jun 12
Added HasAddr32|64 to all the patterns.
@sbc100 Like I said, I think these silent truncations by using explicit types are a maintenance problem which the guidelines mention.
Refactored atomic patterns
as for auto, indeed its says "Use auto if and only if it makes the code more readable or easier to maintain". That was exactly my point when I mentioned "The reason I replaced these with auto is we had a bunch of spots where we had unnecessary truncation because of a uint32_t var = exp that results in a 64-bit value. Using auto avoids these problems, now, and with future changes."
Changed init expr to use all union types, and added code to check for opcode.
Other misc code review.
Fixed linker error due to tablegen adding both generated functions to same #ifdef :(
Thu, Jun 11
Mon, Jun 8
Added HasAddr64 to patterns, and made it default for instructions.
@aheejin yes, this is part of the triple, much like x86 vs x64. That structure was already in place before I started.
Jun 4 2020
Removed one more datalayout
Jun 1 2020
Made several tests pass under wasm64!
May 29 2020
fixed all type errors + more missing atomics
finished initial tablegen changes
May 28 2020
May 21 2020
Either way, I generally don't think such a small change needs a follow-up commit.
Wow, impressive! Not sure if I am the best person to guarantee this tests the same things as the IR tests did, though.
May 18 2020
May 15 2020
@aheejin Apologies if you think I ignored your comments, I feel I responded to all of them, though maybe I could have responded earlier (I wanted to first bring up your point about adjacency in the debugging subgroup meeting yesterday).
Added differential revision to commit
@dschuff not sure what the actual code looks like, this is part of the Bullet3 tests that failed.
May 14 2020
(forgot to add phabricator url to commit)
forgot 1 .back() reference + clang-format
Allowed DBG_VALUE for stackified regs to appear anywhere between its def-use.
addressed aheejin's last comments.
May 8 2020
May 7 2020
DBG_VALUE $noreg now on pop of stackified reg.
Obsolete, fixed elsewhere since.
Obsolete, fixed elsewhere since.
This patch abandoned in favor of the approach in https://reviews.llvm.org/D79428
This has already landed.
May 5 2020
Apr 30 2020
Apr 27 2020
@aheejin thanks for the comments! As you say, given that stackifying happens across multiple passes, it may be that the approach here is going to be too clumsy/fragile. I am going to first see if a solution that works at or just before MC lowering can work instead, that way all the stackifying changes can remain as they are.
Apr 24 2020
Uploading this for early feedback to see if this goes the right direction.
Apr 16 2020
@saugustine thanks, pushed a fix.
updated target index string descriptions
@sbc100 I'm a fan of small and focussed commits, but not a fan of new functionality without any uses/tests. Given that this commit is not particularly big, I vote to keep it together.
Made values more consistently unsigned thru-out.
Ok, will try to make it more consistently unsigned, given that down the line they will be stored as unsigned anyway. But its still messy, given that at least thru one path they arrive as this TargetIndexLocation which is signed.
Made it explicit in the comments for TargetIndex that these are meant to be unsigned.
Changed encoding to use Yury's variadic WasmLocationArg type.
@yurydelendik one thing about your patch: the variadic argument was previously declared as SignedSizeLEB and emitted with emitSigned, yet your new code reads it as getULEB128 and stores it in an array of uint64_t (which we can't change since its shared code). It doesn't matter much for the current use case, but we might want to be consistent about this storing signed or unsigned values? I see value in it being signed for future use cases, but given the existing DWARFExpression code it may well have to be unsigned.