[PATCH] D140635: Enabled DFAJumpThreading by Default

YangguangLi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 17 07:24:13 PST 2023


Yangguang added a comment.
Herald added a subscriber: StephenFan.

In D140635#4019740 <https://reviews.llvm.org/D140635#4019740>, @nikic wrote:

> In D140635#4019565 <https://reviews.llvm.org/D140635#4019565>, @amehsan wrote:
>
>>> This is much more expensive than when I tested this the last time on August 2nd, 2021: https://llvm-compile-time-tracker.com/compare.php?from=380b8a603c6e8997819726b15a76b8f6c94aa21a&to=abb759c879725b7bc09a466e92c9b9eca7f8f483&stat=instructions:u At that time, the pass was pretty cheap, and as such a reasonable tradeoff. Now this doesn't seem to be the case anymore.
>>
>> Taking the geomean of compile time change in the above table shows 0.23% increase in compile time. That is not acceptable?
>
> Not sure how you arrived at that number (isn't it 0.44% geomean across optimized builds?), but no, these regressions are not acceptable for what the pass does, especially if we already know that it can be much faster.
>
> Some of the regressions might be due to second-order effects (i.e. the transform triggers, and this affects compile-time of other transforms), but there are some really large regressions without code size changes, which indicate that the pass itself is slow. For example libclamav_regex_regexec.c has a 16% regression, configfile.c has a 12% regression and header.c has a 17% regression, all without changes in code size.

Thanks for the info! We are now working on the fix for the compile time issue.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140635/new/

https://reviews.llvm.org/D140635



More information about the llvm-commits mailing list