This is an archive of the discontinued LLVM Phabricator instance.

[JITLink] Add target features to LinkGraph
ClosedPublic

Authored by jobnoorman on Apr 29 2023, 12:07 PM.

Details

Summary

This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.

One example, and the reason this patch was written, is linker relaxation
on RISC-V: different relaxations are possible depending on if the C
extension is enabled.

Note that the features are stored as std::vector<std::string> to prevent a
public dependency on MC. There is still a private dependency to be able to
convert SubtargetFeatures to a vector.

Diff Detail

Event Timeline

jobnoorman created this revision.Apr 29 2023, 12:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 29 2023, 12:07 PM
Herald added subscribers: asb, luke, pmatos and 22 others. · View Herald Transcript
jobnoorman requested review of this revision.Apr 29 2023, 12:07 PM
lhames added a comment.May 4 2023, 1:56 AM

Another quick skim (I'm back in the office on Monday and I can take a proper look then).

However, this introduces a dependency from JITLink on MC and I'm not quite sure if this is warranted. If not, the features could be stored as std::vector<std::string> (the underlying storage of SubtargetFeatures).

Yeah -- we definitely want to avoid the dependence on MC. One of the aims of ORC development over the next year or so is going to be splitting the library up so that ORC core depends only on libObject (and eventually, only on format-specific object file parsing libraries, but we don't have those yet. :) )

  • Lang.

Yeah -- we definitely want to avoid the dependence on MC. One of the aims of ORC development over the next year or so is going to be splitting the library up so that ORC core depends only on libObject (and eventually, only on format-specific object file parsing libraries, but we don't have those yet. :) )

That makes sense. Unfortunately, it isn't as easy to avoid as I thought. The problem is that to get the features from an object file, we have to call ObjectFile::getFeatures which returns a SubtargetFeatures and we have to call one of its methods to convert it to a std::vector<std::string>. So I don't immediately see a way around the MC dependency.

On a related note: I wonder why SubtargetFeatures is part of MC and not of, say, TargetParser (like Triple).

lhames added a comment.May 4 2023, 4:16 PM

Yeah -- we definitely want to avoid the dependence on MC. One of the aims of ORC development over the next year or so is going to be splitting the library up so that ORC core depends only on libObject (and eventually, only on format-specific object file parsing libraries, but we don't have those yet. :) )

That makes sense. Unfortunately, it isn't as easy to avoid as I thought. The problem is that to get the features from an object file, we have to call ObjectFile::getFeatures which returns a SubtargetFeatures and we have to call one of its methods to convert it to a std::vector<std::string>. So I don't immediately see a way around the MC dependency.

On a related note: I wonder why SubtargetFeatures is part of MC and not of, say, TargetParser (like Triple).

Huh. That's a really good question. Maybe we can do this by moving SubtargetFeatures?

If we can't do that (or want a short term solution) then we should use std::vector<std::string> on the LinkGraph and hide the MC dependency in the implementation code. That'll make it easier to fix later without breaking clients.

jrtc27 added a comment.May 4 2023, 4:17 PM

Dumb question perhaps, but why can't JITLink use MC? LLD does and conceptually serves a similar purpose.

On a related note: I wonder why SubtargetFeatures is part of MC and not of, say, TargetParser (like Triple).

Huh. That's a really good question. Maybe we can do this by moving SubtargetFeatures?

fyi: I posted a question about this on Discourse.

lhames added a comment.May 7 2023, 7:24 PM

Dumb question perhaps, but why can't JITLink use MC? LLD does and conceptually serves a similar purpose.

JITLink is used in some systems where memory and storage are at a premium, so we want our dependencies to be as minimal as possible. We're stuck right now (libObject pulls in LLVM Core), but the eventual goal is to (1) break format-specific parsers out of libObject, and then (2) have a JITLink core library that depends on libSupport only, plus format specific libraries (JITLinkCOFF, JITLinkELF, and JITLinkMachO) that each depend on the corresponding format-specific parser only.

jobnoorman edited the summary of this revision. (Show Details)

Store features as std::vector<std::string> to prevent a public dependency on MC.

On a related note: I wonder why SubtargetFeatures is part of MC and not of, say, TargetParser (like Triple).

Huh. That's a really good question. Maybe we can do this by moving SubtargetFeatures?

If we can't do that (or want a short term solution) then we should use std::vector<std::string> on the LinkGraph and hide the MC dependency in the implementation code. That'll make it easier to fix later without breaking clients.

Even though I opened D150549 to try and move SubtargetFeatures, I don't expect it to land anytime soon (if ever). Therefore, I've updated this patch to only use MC in implementation code. If that patch does land, we can update how features are stored then.

The cantFails should be resolved (either commented if they truly can't fail, or removed if they could), but otherwise LGTM.

llvm/lib/ExecutionEngine/JITLink/COFFLinkGraphBuilder.cpp
32

I think I missed this the first time around. Why cantFail? There should be a comment explaining why, at this particular call-site, it would be impossible for this call to ever fail. If it could fail then the API needs to be refactored to return an Error / Expected (in the case of constructors this usually means switching to a named constructor idiom, or you could check/retrieve the FeatureVector in the caller, then pass it into this constructor).

Remove all uses of cantFail; propagate errors instead.

jobnoorman marked an inline comment as done.May 16 2023, 1:19 AM
jobnoorman added inline comments.
llvm/lib/ExecutionEngine/JITLink/COFFLinkGraphBuilder.cpp
32

You're right, this use of cantFail wasn't appropriate. I convinced myself after a cursory glance that getFeatures never fails for any architecture and that cantFail would therefore be an easy solution. This isn't true, however, so I've updated the patch to propagate errors.

lhames accepted this revision.May 17 2023, 1:37 AM

LGTM. Thanks very much for all of your work on this @jobnoorman!

Side note, it looks like https://reviews.llvm.org/D150549 got at least one thumbs up already. If/when that lands we would benefit from going back to using SubtargetFeatures in LinkGraph, since it'll save us copying the vector (no that this is going to cost much in practice).

This revision is now accepted and ready to land.May 17 2023, 1:37 AM
This revision was automatically updated to reflect the committed changes.
jobnoorman marked an inline comment as done.

Thanks for the reviews @lhames!

Side note, it looks like https://reviews.llvm.org/D150549 got at least one thumbs up already. If/when that lands we would benefit from going back to using SubtargetFeatures in LinkGraph, since it'll save us copying the vector (no that this is going to cost much in practice).

Agreed. Once that one lands, I'll submit a JITLink patch for this.