Are you aware of p2900?

On Sun, Jun 1, 2025, 11:32 SD SH via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> True, but not only inlined functions.
> It can make compiler jump to the excepted branch without redundant
> check-ups. We can even use 1 function and many tag.
> Like this:
>
> _func:
> ; fastcall
> ; rcx = int para1
> ; rdx = bool para2
> cmp rdx, 0
> jne _func_para2_true
> cmp rcx, 0
> jl _func_para2_true_para1_l0
> _func_para2_false_para1_geq0
> ; ...
> ret
> _func_para2_true:
> ; ...
> ret
> _func_para2_true_para1_l0:
> ; ...
> ret
>
> In fact, even if compiler not inlined the function, it still works.
> For example, _func(i assure(i >= 0, b assure(!b)) will be:
> call _func_para2_false_para1_geq0
> And 2 branches will be skipped.
>
> I think compiler couldn't do above well.
> ------------------------------
> *发件人:* Std-Proposals <std-proposals-bounces_at_[hidden]> 代表
> Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
> *发送时间:* 2025年6月1日 21:25
> *收件人:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *抄送:* Sebastian Wittmeier <wittmeier_at_[hidden]>
> *主题:* Re: [std-proposals] A Proposal about A New Keyword assure
>
>
> Do I understand that correctly that you are talking about getting gains
> with inlined functions by giving additional static (constexpr expression)
> constraints at the call-site?
>
>
>
> Why is it better (except syntax) compared to existing facilities?
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* SD SH via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* So 01.06.2025 15:19
> *Betreff:* [std-proposals] A Proposal about A New Keyword assure
> *An:* std-proposals_at_[hidden];
> *CC:* SD SH <Z5515zwy_at_[hidden]>;
> This proposal introduces a new contextual-keyword assure that allows
> callers to declare parament Constraints at function call sites. can
> utilizing these Constraints to optimize function calling. (e.g. removing
> branches) Violations result in undefined behavior. Analogous to [[assume]].
>
> Motivation
> Check-ups of function definition sites is unnessary at some call
> sites, but compilers may preserve check-ups for them. Sometimes we need
> more performance optimizations but we can't do many optimizations such as
> built-in functions and third-party libraries.
> e.g. Lighting computing will call sqrt many times.
> If sqrt(double _X) like this:
> double __fastcall sqrt(double _X)
> {
> if(_X < 0.0)
> {
> return std::numeric_limits<double>::infinity();
> }
> else
> {
> // ...
> }
> }
> // asm:
> /*
> _sqrt:
> pxor xmm1, xmm1
> ucomisd xmm0, xmm1
> jl _sqrt__Xl0
> ; ...
> _sqrt__Xl0:
> movsd xmm0, 0x7FF8000000000000
> ret
> */
> In lighting computing, _X is always equals zero or greater than
> zero, so branch of if(_X < 0.0) is never performed there, but compiler may
> not remove it.
> assure will slove this issue.
> sqrt(d assure(d >= 0)) may generates
> _sqrt:
> pxor xmm1, xmm1
> ucomisd xmm0, xmm1
> jl _sqrt__Xl0
> _sqrt_sometime:
> ; ...
> ret
> _sqrt__Xl0:
> movsd xmm0, 0x7FF8000000000000
> ret
> ;...
> movsd xmm0, [somewhere]
> call _sqrt_simetime
> or inline call or a new function of sqrt, we needn't program
> another sqrt for this call site and compiler can optimize program better.
> Design Decisions
> Syntax
> func(para1 assure(const-bool-expr(INPUT: { para1, const paras...
> })), paras...)
>
> Rejected Alternatives:
> func(paras...) assure(const-bool-expr(INPUT: const paras...))
> makes compiler implementation difficult.
> Semantics:
> Constraints are purely caller-to-compiler optimization hints.
> Expressions must be side-effect-free and dependent only on
> caller-visible state.
> Expressions should be true, or function calling has undefined
> behavior
> Alternative Considered:
> Runtime assertions (for security) rejected due to performance
> impact.
>
> Ecosystem Impact
> User: Performance gains with constraints
> Implementers: Medium or low implementation effort
> STL: Greater room for optimization
>
> View the full text (R0) on GitHub: CPP-Proposals/assure.txt
> <https://github.com/TheNameofSH/CPP-Proposals/blob/main/assure.txt>
>
> Thank you!
>
> E. S. Himers <Z5515zwy_at_[hidden]>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>