kovdan01 wrote: @ojhunt It's definitely worth measuring performance and collecting benchmarks to see if we have significant performance regressions with these new changes, thanks for bringing attention to this!
BTW, were you able to address the regressions you've mention here? > The parsing itself should have been overwhelmed by the complexity of the > dispatch yet I found significant performance regressions. Anyway, would it be suitable if we investigate this separately and merge this "as is" (if there are no other objections)? I've created a corresponding issue #174077 for tracking the investigation work The reason why I suggest to investigate this separately is that unfortunately I'll have no chance to do the investigation in January. But merging this PR in January so we can include that in the upcoming release looks like a good idea because the patch it's definitely beneficial from security perspective. As for your suggestion: > I actually wonder if we should make a pointer wrapper that can handle ptrauth > types - it would make the behavior much more explicit and would Just Work > (tm) as a parameter by making the argument type non-pod, and the inliner can > flatten from there. I think it would be worth to measure performance with current implementation and with the suggested one and see the difference. Unfortunately we'll not be able to test performance for all the architectures, but we can at least do that for regular x86-64, regular aarch64 and aarch64 with pauth-enabled ABI. Until we have some benchmarks, I do not think that we should change the implementation because I'm actually not sure that such a wrapper would behave as "zero-cost abstraction" https://github.com/llvm/llvm-project/pull/173765 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
