Inline more trivial functions #10880
Conversation
nordlow
requested review from
CyberShadow,
ibuclaw and
jmdavis
as code owners
|
Thanks for your pull request and interest in making D better, @nordlow! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub run digger -- build "master + phobos#10880" |
| } | ||
| } | ||
|
|
||
| pragma(inline, true) |
There was a problem hiding this comment.
This file is auto-generated by tools/unicode_table_generator.d, so it should be modified in the toSourceCode function at std/uni/package.d.
There was a problem hiding this comment.
Leave this module alone please.
Unicode tables are one place where the value is much lower in inlining due to the cost of the algorithms that call them.
There was a problem hiding this comment.
We'll merge this once the pragmas are removed from this file.
There was a problem hiding this comment.
@LightBender What's the answer to #10880 (comment) ?
| } | ||
| } | ||
|
|
||
| pragma(inline, true) |
There was a problem hiding this comment.
Leave this module alone please.
Unicode tables are one place where the value is much lower in inlining due to the cost of the algorithms that call them.
|
I don't understand what this pull request is trying to solve. The point of the inline pragma is to override the optimizer's decisions. It should be used only when the optimizer has made an incorrect decision. The optimizer is also highly specific to the backend. I can see how the pragma can be useful in specific scenarios where profiling and disassembling revealed that the specific optimizer has made a suboptimal decision with a specific program. I don't see how this applies to the standard library, which can be compiled by any D compiler. So, isn't the correct number of |
|
Anyway I think it should be measured when adding inline attributes.
Q: I believe it's useful for cross-module inlining in LDC (although LDC has a |
|
Maybe, but is that the right solution? We would then be using a vendor-agnostic compiler directive to improve one specific vendor's compiler. |
6 participants
No description provided.