This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Refactor order of creation for SyntheticFunction
ClosedPublic

Authored by ncw on Mar 7 2018, 6:28 AM.

Details

Summary

Previously we created __wasm_call_ctors with null InputFunction, and added the InputFunction later. Now we create the SyntheticFunction with null body, and set the body later.


This will allow placing SyntheticFunctions at the start of the Wasm file. This is a useful refactor I think! You may think otherwise...

Diff Detail

Repository
rLLD LLVM Linker

Event Timeline

ncw created this revision.Mar 7 2018, 6:28 AM
ruiu added a comment.Mar 7 2018, 9:17 AM

I'd guess that the motivation of this change is to start processing global constructors as quickly as possible by putting them at beginning of a file when we execute a wasm binary with a streaming decoder & executor. Am I correct?

ncw added a comment.EditedMar 7 2018, 9:34 AM

I'd guess that the motivation of this change is to start processing global constructors as quickly as possible by putting them at beginning of a file when we execute a wasm binary with a streaming decoder & executor. Am I correct?

Yes, that's right :) There's a TODO to that effect in Writer::assignIndexes, I should probably add a short permanent comment just as well to note that it's desirable for __wasm_call_ctors to come early on.

Secondarily, it's also a very nice simplification to Writer::createCtorFunction, which previously did all sorts of stuff with indexes and the Live bit.. three or four lines of duplicated code from elsewhere in Writer, whereas creating the SyntheticFunction object up-front means that's all handled automatically at the same as those are set for all the other InputFunctions.

ruiu added a comment.Mar 7 2018, 9:39 AM

If that's the case, I don't think just putting a .ctor at beginning of a file is not enough. You probably should sort functions by topological order so that the functions and data that a .ctor needs are available early.

sbc100 accepted this revision.Mar 7 2018, 9:42 AM

Nice. I like this increased abstraction and generalization this buys us.

LGTM, with comments.

wasm/SymbolTable.h
55

Newline between method bodies.

82

Maybe move these up to where ObjectFiles is defined (and make them public). They seem to fit the same category to me, and it would save adding accessors.

wasm/Writer.cpp
884

Should use cast<> here and define a classof() for syntheticfunction? Would that buy is anything?

This revision is now accepted and ready to land.Mar 7 2018, 9:42 AM
sbc100 added a comment.Mar 7 2018, 9:46 AM

If that's the case, I don't think just putting a .ctor at beginning of a file is not enough. You probably should sort functions by topological order so that the functions and data that a .ctor needs are available early.

I don't see that as the reason for this change. This seems like more of refactor to make the code cleaner and more re-usable. Nicolas has another change pending that will add synthetic functions to allow weak undefined functions to be called which builds on the generality in this change.

I fact, this change doesn't change the order of any functions, as can be seen by the fact that no unit tests changed.

@ncw, and you add NFC to the title and update the title and the description to more accurately describe what this change does. Its not really just about the __wasm_call_ctors, and it doesn't effect the ordering in the file, right?

sbc100 added a comment.Mar 7 2018, 9:48 AM

Also, it should be noted that it is too early to say if ordering of the functions withing the wasm file means anything to any of the engines, so any change that was aimed purely at that would be premature.

ruiu added a comment.Mar 7 2018, 10:30 AM

I'm not sure if this is a good change as a refactoring...

wasm/Driver.cpp
302–303

I think you should directly pass make's return value instead because you are using it only once.

wasm/InputChunks.h
165–168

I don't actually know if this is a good thing. Currently a syntehtic function is immutable, but now with this change it is mutable. It is not a good thing in general.

ncw updated this revision to Diff 137429.Mar 7 2018, 10:37 AM
ncw marked 3 inline comments as done.
ncw retitled this revision from [WebAssembly] Create SyntheticFunction for __wasm_call_ctors earlier to [WebAssembly] Refactor order of creation for SyntheticFunction.
ncw edited the summary of this revision. (Show Details)

Updated: nits, clang-format, and added classof for SyntheticFunction

ncw added inline comments.Mar 7 2018, 10:39 AM
wasm/InputChunks.h
165–168

There's an upside and a downside - previously we were mutating the DefinedFunction symbol object. So there's no extra mutation, it's just shifted from one object to another. It's "safer" I think to mutate the SyntheticFunction, since nothing looks at its body until the very end (when the CODE section is written out), whereas it's more dangerous to mutate the symbol, since various fields are retrieved from it earlier on.

sbc100 added inline comments.Mar 7 2018, 10:48 AM
wasm/InputChunks.h
165–168

I agree with @ncw here. Previously we were mutating the symbol to point to an entirely new function, not we are only mutating the body of the function and leaving the symbol alone.

I can see more refinements here down the road but think this is step forward.

ruiu added inline comments.Mar 7 2018, 10:54 AM
wasm/InputChunks.h
165–168

I don't like the fact that this class has two ways to set body. But you can eliminate Body from the constructor , no?

ncw marked an inline comment as done.Mar 9 2018, 8:45 AM
ncw added inline comments.
wasm/InputChunks.h
165–168

Done, removed Body from the constructor

This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.
ncw marked an inline comment as done.