On Thu, 2024-11-14 at 16:27 -0800, Alexei Starovoitov wrote: [...] > Well, I asked whether it makes a difference. > And looks like your numbers show that this optimization adds 101m to 116m ? No, it does not make a difference for dynptr_slice: > > - The patches #1,2 with opt_hard_wire_dead_code_branches() changes are > > not necessary for dynptr_slice kfunc inlining / branch removal. > > I will drop these patches and adjust test cases. The 101m -> 116m is for inlining w/o known branch removal -> inlining with branch removal. (With 76m being no inlining at all). > If so, it's worth doing. I still don't like two bool flags though. The peaces of information to encode here are: - whether the branch is always predicted; - if so, which branch. I don't think this could be narrowed down to a single bit.
