This is an archive of the discontinued LLVM Phabricator instance.

[TTI][BPF] Ensure ArgumentPromotion Not Exceeding Target MaxArgs
ClosedPublic

Authored by yonghong-song on Apr 17 2023, 11:27 AM.

Details

Summary

With LLVM patch https://reviews.llvm.org/D148269, we hit a linux kernel
bpf selftest compilation failure like below:

... 
progs/test_xdp_noinline.c:739:8: error: too many args to t8: i64 = GlobalAddress<ptr @encap_v4> 0, progs/test_xdp_noinline.c:739:8
            if (!encap_v4(xdp, cval, &pckt, dst, pkt_bytes))
                 ^   
... 
progs/test_xdp_noinline.c:321:6: error: defined with too many args
bool encap_v4(struct xdp_md *xdp, struct ctl_value *cval,
     ^   
...

Note that bpf selftests are compiled with -O2 which is
the recommended flag for bpf community.

The bpf backend calling convention is only allowing 5
parameters in registers and does not allow pass arguments
through stacks. In the above case, ArgumentPromotionPass
replaced parameter '&pckt' as two parameters, so the total
number of arguments after ArgumentPromotion pass becomes 6
and this caused later compilation failure during instruction
selection phase.

This patch added a TargetTransformInfo hook getMaxNumArgs()
which returns 5 for BPF and UINT_MAX for other targets.

Diff Detail

Event Timeline

yonghong-song created this revision.Apr 17 2023, 11:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 17 2023, 11:27 AM
yonghong-song requested review of this revision.Apr 17 2023, 11:27 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 17 2023, 11:27 AM
yonghong-song retitled this revision from [RFC][TTI][BPF] Ensure ArgumentPromotion Not Exceeding Target MaxArgs to [TTI][BPF] Ensure ArgumentPromotion Not Exceeding Target MaxArgs.
yonghong-song edited the summary of this revision. (Show Details)
yonghong-song added reviewers: nikic, aeubanks.
  • add a test case

what about combining arguments in the backend (basically undoing this transformation)? that would generalize better to other passes and input IR

llvm/test/CodeGen/BPF/argumentpromotion.ll
1 ↗(On Diff #514398)

this should only run argument promotion, not the entire O2 pipeline

also, this test case needs to be reduced a lot more, there's a lot of unrelated things in the IR here

  • for added test, do not use -O2, use -passes=argpromotion instead for opt. Also put the test under test/Transformations/ArgumentPromotion/BPF directory similar to ArgumentPromotion/X86.

what about combining arguments in the backend (basically undoing this transformation)? that would generalize better to other passes and input IR

I would prefer to use a TTI hook as the hook itself essentially a profitability check. If the number of arguments is greater than the backend specified, the transformation is not profitable.
I suspect any other phases to do similar argument expanding transformation. If this does happen, we can use the same hook in those other transformations.

In our case, if input IR contains more than 5 arguments, the compiler will error out. This is okay and expected in bpf community since it is explicit in BPF specification that maximum 5 arguments are allowed. We do not need to add optimization to cope with such cases. We only need to deal with cases where user code is valid in terms of number of arguments but the compiler transformation makes it invalid.

llvm/test/CodeGen/BPF/argumentpromotion.ll
1 ↗(On Diff #514398)

Good suggestion. Just remove O2 and run argument promotion only for the test. Also simplified the input IR a lot.

aeubanks accepted this revision.Apr 18 2023, 8:22 PM

lgtm with test cleanup

llvm/test/Transforms/ArgumentPromotion/BPF/argpromotion.ll
26

a lot of this can still be removed, like dso_local, local_unnamed_addr, fastcc

This revision is now accepted and ready to land.Apr 18 2023, 8:22 PM
  • remove function 'annotation' like dso_local, fastcc, local_unnamed_addr, unnamed_addr, as they won't affect argspromotion transformation.
llvm/test/Transforms/ArgumentPromotion/BPF/argpromotion.ll
26

done!

ast accepted this revision.Apr 19 2023, 8:56 AM
This revision was landed with ongoing or failed builds.Apr 19 2023, 9:12 AM
This revision was automatically updated to reflect the committed changes.