This isn't something that would make sense for standardization. First it
would need more compiler research. Just my two cents: This is approaching
the problem from the wrong angle. Ideally you'd want inlining to address
things like this, but also look into things like function cloning.

Cheers,
Jeremy

On Sun, Jun 1, 2025 at 8:19 AM SD SH via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>