Page MenuHomePhabricator

WebAssembly: generate global loads
AbandonedPublic

Authored by jfb on Aug 26 2015, 6:13 PM.

Details

Reviewers
sunfish
Summary

I'll add global store as a follow-up.

Note that WebAssembly globals *must* be address not-taken, which allows for some magical optimizations by the in-browser JIT. The LLVM backend will need to linearize all address-taken globals into a heap, and GEP into that special global (and that'll need appending linkage when mashing object files together). This will be done later.

Diff Detail

Event Timeline

jfb updated this revision to Diff 33292.Aug 26 2015, 6:13 PM
jfb retitled this revision from to WebAssembly: generate global loads.
jfb updated this object.
jfb added a reviewer: sunfish.
jfb added a subscriber: llvm-commits.
jfb added a comment.Aug 26 2015, 9:16 PM

This patch is still incomplete, I just want to check the general direction makes sense with @sunfish. I'll move the definitions to the right place and handle all relevant types before committing (and test them).

I also realized that my previous patch should have handled i8 and i16 globals (since they're memory types), so I'll send a separate patch to do so, and then update this one with the appropriate types.

I would like to propose a different approach to global variables.

We should start by allocating all global variables inside the address space, using a plain old data section. This will be easy to do, it's what LLVM normally does, it'll support all global variables, and it's something we'll need to do anyway. And, it'll be easier to do if we don't have to contend with special-case tglobaladdr patterns up front.

Once that's done, we can talk about how best to optimize non-address-taken globals.

jfb added a comment.Aug 27 2015, 9:51 AM

I would like to propose a different approach to global variables.

We should start by allocating all global variables inside the address space, using a plain old data section. This will be easy to do, it's what LLVM normally does, it'll support all global variables, and it's something we'll need to do anyway. And, it'll be easier to do if we don't have to contend with special-case tglobaladdr patterns up front.

Once that's done, we can talk about how best to optimize non-address-taken globals.

I'm not sure I understand what you propose: I want to map C++ non-address-taken variables to wasm globals, which aren't in linear memory and can't alias with linear memory. Trying to make sense of what you propose: we could move all address-not-taken variables to their own section, and then perform the lowering I propose?

We could also start by just ignoring wasm globals entirely (just have load/store and linear memory).

jfb abandoned this revision.Aug 27 2015, 9:58 AM

We discussed this offline, @sunfish was indeed suggesting that we handle globals later as an optimization, and only do linear memory for now. This sounds sensible, so I'll close the issue for now!