This is an archive of the discontinued LLVM Phabricator instance.

[Clang] Propagate target-features if compatible when using mlink-builtin-bitcode
ClosedPublic

Authored by jmmartinez on Aug 30 2023, 7:42 AM.

Details

Summary

Buitlins from AMD's device-libs are compiled without specifying a
target-cpu, which results in builtins without the target-features
attribute set.

Before this patch, when linking this builtins with -mlink-builtin-bitcode
the target-features were not propagated in the incoming builtins.

With this patch, the default target features are propagated
if they are compatible with the target-features in the incoming builtin.

Diff Detail

Event Timeline

jmmartinez created this revision.Aug 30 2023, 7:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2023, 7:42 AM
jmmartinez requested review of this revision.Aug 30 2023, 7:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 30 2023, 7:42 AM
arsenm added inline comments.Aug 30 2023, 7:52 AM
clang/lib/CodeGen/CGCall.cpp
2034

Really it would be less bad if the incompatible functions were not imported rather than the backend pass

2035

do you need to guard against adding the empty attribute? I don't want to see "target-features"=""

clang/test/CodeGen/link-builtin-bitcode.c
17

This isn't a real target feature (do we not have a warning on this?)

s/uncompatible/incompatible

jmmartinez marked 2 inline comments as done.Aug 30 2023, 9:35 AM
jmmartinez added inline comments.
clang/lib/CodeGen/CGCall.cpp
2034

I thought it was possible to have functions with incompatible features in the same module.
e.g. one function compiled with some instruction set support, one without, and an ifunc that resolves to one or the other.

Maybe it's not the case in the context of -mlink-builtin-bitcode?

clang/test/CodeGen/link-builtin-bitcode.c
17

Only when the feature doesn't map to any "+" or "-" feature.

If I use "foo-insts" I get a warning because there are no +foo-insts / -foo-insts (and it still ends up in the generated llvm-ir)

jmmartinez marked an inline comment as done.
  • Drop incoming builtins with incompatible target-features
jmmartinez added inline comments.Aug 30 2023, 9:38 AM
clang/lib/CodeGen/CodeGenAction.cpp
282 ↗(On Diff #554753)

Remove { }

arsenm added inline comments.Aug 30 2023, 4:40 PM
clang/lib/CodeGen/CGCall.h
398–401 ↗(On Diff #554753)

i think this should be done in a separate patch, just propagate + append for step 1. There are other edge cases I'm worried about handling with this

  • Rollback, drop incompatible functions in a separate commit
arsenm added inline comments.Aug 31 2023, 3:49 PM
clang/lib/CodeGen/CGCall.cpp
2017

Do you need to guard against empty string?

2018

consume_front

2021

Capitalize

2027

Capitalize

2030–2031

Early return breaks the other features

jmmartinez updated this revision to Diff 555691.Sep 4 2023, 2:18 AM
jmmartinez marked 4 inline comments as done.
  • Review
jmmartinez added inline comments.Sep 4 2023, 2:20 AM
clang/lib/CodeGen/CGCall.cpp
2017

I checked and I saw some tests without it. I'm adding the condition for it.

2018

I used drop_front(1) instead, consume_front would only work with "+" and not drop "-".

2030–2031

I did not understand this remark.

If the features are not compatible, we do not add a "target-features" entry in the new "FuncAttrs". Then, the old "target-features" entry is kept in the Function coming from the builtin.

If you think it would be better to set the target-features in FuncAttrs to the old value in any case. If that's the case I've added the following code:

if (EnabledForTarget != EnabledForFunc) {
    FuncAttr.addAttribute(FFeatures);
    return;
}
arsenm added inline comments.Sep 5 2023, 1:27 PM
clang/lib/CodeGen/CGCall.cpp
2030–2031

You find an incompatible feature and then discontinue processing any further features by early exiting. I expect this to act like an append to any features already present. The incompatibility is at an individual feature level, not the group

2034

The truth is this system isn't really well considered. We don't have real ifunc support and we probably shouldn't be using subtargets for cases with incompatible encodings

jmmartinez updated this revision to Diff 555986.Sep 6 2023, 1:47 AM
jmmartinez marked an inline comment as done.
  • Review
jmmartinez updated this revision to Diff 555987.Sep 6 2023, 1:51 AM
jmmartinez marked 2 inline comments as done.
  • Capitalize comment
clang/lib/CodeGen/CGCall.cpp
2030–2031

I see. I changed it to match that behaviour.

arsenm accepted this revision.Sep 8 2023, 1:29 AM
This revision is now accepted and ready to land.Sep 8 2023, 1:29 AM
yaxunl added inline comments.Sep 8 2023, 6:31 AM
clang/lib/CodeGen/CGCall.cpp
2006

can you add a comment about how the original target feature attributes of the function that is incompatible or missing in the target feature are handled.

clang/test/CodeGen/link-builtin-bitcode.c
46

The irrelevant function attributes should not be checked

@yaxunl I've addressed your remarks on a GitHub PR: https://github.com/llvm/llvm-project/pull/65938

Thanks for the remarks! It made me realize that I could simplify the code a lot.