This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] TargetStreamer cleanup (NFC)
ClosedPublic

Authored by aheejin on Dec 5 2018, 4:52 PM.

Details

Summary
  • Unify mixed argument names (Symbol and Sym) to Sym
  • Changed MCSymbolWasm* argument of emit*** functions to const MCSymbolWasm*. It seems not very intuitive that emit function in the streamer modifies symbol contents.
  • Moved empty function bodies to the header
  • clang-format

Diff Detail

Event Timeline

aheejin created this revision.Dec 5 2018, 4:52 PM
aheejin updated this revision to Diff 176914.Dec 5 2018, 6:21 PM

More cleanups

aheejin retitled this revision from [WebAssembly] Make variable names consistent in TargetStreamer (NFC) to [WebAssembly] TargetStreamer cleanup (NFC).Dec 5 2018, 6:21 PM
aheejin edited the summary of this revision. (Show Details)
aheejin edited the summary of this revision. (Show Details)
aheejin edited the summary of this revision. (Show Details)Dec 5 2018, 6:31 PM
aheejin updated this revision to Diff 176917.Dec 5 2018, 7:23 PM
aheejin edited the summary of this revision. (Show Details)
  • Move more setType to AsmPrinter
aheejin updated this revision to Diff 176921.Dec 5 2018, 7:52 PM
  • clang-format & clang-tidy
sbc100 added inline comments.Dec 6 2018, 8:29 AM
lib/Target/WebAssembly/MCTargetDesc/WebAssemblyTargetStreamer.cpp
137

We have two different streamers WebAssemblyTargetWasmStreamer and WebAssemblyTargetAsmStreamer. I seems that this code is only needed for the object file streamer so moving it out into common code is actually a semantic change.

Can you revert this part or at least put it in separate change so that this one can be a simple NFC?

sbc100 added a comment.Dec 6 2018, 8:35 AM

There is a presensent for the "emit" functions in the streamer modifying symbols. For example:

void MCELFStreamer::emitELFSize(MCSymbol *Symbol, const MCExpr *Value) {         
  cast<MCSymbolELF>(Symbol)->setSize(Value);                                     
}

I'm not saying this is the best, but it seems to have be designed or used this way in other targets, so I'd be tempted to use caution when refactoring. I myself don't have enough to background to know if this is a direction we want to move in. @sunfish and @aardappel might have a better idea.

aardappel accepted this revision.Dec 6 2018, 10:49 AM
This revision is now accepted and ready to land.Dec 6 2018, 10:49 AM
sbc100 added inline comments.Dec 6 2018, 12:04 PM
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp
115

I think it might make sense to continue to have emitImportModule to one thing for the asm case and the other for the binary streamer. Calling setModuleName() is clearly not needed for the asm writer so why do it?

Perhaps the difficulty comes from the fact that WebAssemblyTargetWasmStreamer wants to set attributes on the symbols when maybe it should be storing this "extra" symbol information that only it requires in a side data structure?

aheejin marked 3 inline comments as done.Dec 6 2018, 3:31 PM

There is a presensent for the "emit" functions in the streamer modifying symbols. For example:

void MCELFStreamer::emitELFSize(MCSymbol *Symbol, const MCExpr *Value) {         
  cast<MCSymbolELF>(Symbol)->setSize(Value);                                     
}

I'm not saying this is the best, but it seems to have be designed or used this way in other targets, so I'd be tempted to use caution when refactoring. I myself don't have enough to background to know if this is a direction we want to move in. @sunfish and @aardappel might have a better idea.

I checked streamers of other targets and it was kind of 50/50 (const / non-const). So I don't feel very strongly about putting const in there. And I thought MCSymbolWasm's type is a symbol's inherent property, so it is not necessarily be only assocaited with object files. WebAssemblyMCInstLower sets types to symbols even before does not know whether it will emit .s or .o file.

But anyway I don't feel strongly about this, so I can revert setType and setModuleName related part if you suggest so.

lib/Target/WebAssembly/MCTargetDesc/WebAssemblyTargetStreamer.cpp
137

If AsmStreamer does not use this property, isn't it NFC anyway? No tests can be affected.

aheejin marked 3 inline comments as done.Dec 7 2018, 2:16 PM
aheejin added inline comments.
lib/Target/WebAssembly/MCTargetDesc/WebAssemblyTargetStreamer.cpp
83

For emitGlobalType and emitEventType we check if the given symbol is global or event type even in AsmStreamer, which supports what I said before: Symbol types are just inherent properties of symbols and should not necessarily be tied to asm case vs. obj case. But if we try to add the same assertion to WebAssemblyTargetAsmStreamer::emitFunctionType above (which I did), it fails without my change in this CL that moves setType(wasm::WASM_SYMBOL_TYPE_FUNCTION) to AsmPrinter.

aheejin marked 2 inline comments as not done.Dec 7 2018, 2:17 PM

We have 4 possible paths of emitting code (backend vs assembler, binary vs asm), so my answer for "where should this setType call go" is "wherever it makes those 4 paths most uniform / least fragile".

That said, I'd say having the streamer setting state on symbols feels somewhat weird to me, given that a streamer is mostly a dumb byte/text writer, and not responsible for managing state (symbols are owned by MCContext, outside of the streamer). But again, the above rule is more important to me :) We have a lot of places in the code that are somewhat weird, because we're a nonstandard "CPU", so I don't think that should be of primary concern.

aheejin added a comment.EditedDec 10 2018, 11:50 AM

We have 4 possible paths of emitting code (backend vs assembler, binary vs asm), so my answer for "where should this setType call go" is "wherever it makes those 4 paths most uniform / least fragile".

That said, I'd say having the streamer setting state on symbols feels somewhat weird to me, given that a streamer is mostly a dumb byte/text writer, and not responsible for managing state (symbols are owned by MCContext, outside of the streamer). But again, the above rule is more important to me :) We have a lot of places in the code that are somewhat weird, because we're a nonstandard "CPU", so I don't think that should be of primary concern.

This patch is trying to make those 4 paths more uniform. Some paths call setType during the code generation part before it reaches the streamer, and others call it during the streamer. What I suggest is, if we want to set symbols' properties (such as calling setType or setModuleName) within the streamer, we should do that for all paths. Otherwise we should do that outside of the streamer for all paths.

Then yes, whichever you think is more uniform I am cool with.

@sbc100 Do you have any concerns on landing this?

sbc100 accepted this revision.Dec 10 2018, 2:42 PM

If @aardappel and @dschuff are ok with this change I'll defer to them.

aheejin added a comment.EditedDec 10 2018, 2:47 PM

@dschuff Do you think this looks OK?

dschuff accepted this revision.Dec 10 2018, 4:06 PM

At a high level (i.e. across all the LLVM targets) the intention is that binary and asm streamers have the same interface. That's sort of enforced by the fact that they both have the same base class, but I guess in actuality the "interface" also includes the data on the symbol object. I think I agree that it makes more sense to think of the symbols as owned outside the streamer and have them be a way to pass info into the streamer (the current code is more like having them be state that is only needed by the binary streamer but which lives outside the streamer). I guess that's also another way of saying that symbol type and module name are properties of a symbol even if those properties are only needed by one of the streamers. I guess it might also be useful for debugging or future modifications to have the contents of the symbols be the same regardless of which output type is in use.

So... I guess that's a long-winded way of saying LGTM?

This revision was automatically updated to reflect the committed changes.

Thank you all for comments!