Contrary to ELF, we don't add any markers that distinguish data generated with .short/.long from normal instructions, so the .inst directive only adds compatibility with assembly that uses it.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I can't comment too much on the use of .inst in machO and Windows. I have a small suggestion that might make it possible to share more of the implementation, but it is only a personal preference.
lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp | ||
---|---|---|
52 ↗ | (On Diff #157764) | This looks almost identical to ARMELFStreamer::emitInst() with just the EmitARMMappingSymbol() and EmitThumbMappingSymbol(). Would it be possible to add a hook for adding the mapping symbol that the ELF backend can override and then make it use the implementation in ARMTargetStreamer? |
lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp | ||
---|---|---|
52 ↗ | (On Diff #157764) | Yes, it's identical except for that, and minus some asserts about IsThumb which isn't available here. Sharing in one way or another is doable, but it requires a little more than that. The ARMELFTargetStreamer::emitInst() method calls ARMELFStreamer::emitInst(), which contains the body of the method implementation, that we'd like to share. But ARMELFStreamer::EmitBytes() also overrides MCELFStreamer::EmitBytes to force adding a data symbol in front of it. So we can't have ARMTargetStreamer just call getStreamer().EmitBytes(StringRef(Buffer, Size)); since that will get the extra data prefix prepended. So we can:
|
lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp | ||
---|---|---|
52 ↗ | (On Diff #157764) | Thanks for pointing that out; it is more complicated than I first thought. One possible alternative could be to add an overaload of emitInst with a MCObjectStreamer parameter to ARMTargetStreamer which we could call emitBytes() and potentially add the mapping symbol hooks to. The backend overrides of emitInst could add the appropriate streamer. This is getting to the point where the extra code to factor out the duplication may not be worth it. I suggest seeing if anyone else has any preferences. |
@peter.smith, yeah, I think that sharing this might make it more complex. This looks fine to me, any other concerns?