Are there many documented cases where providing more (true) information to
the compiler leads to worse code gen? What kind of cases are those?

Thinking of a C++26 codebase that has a bunch of contracts, where the
compiler can be configured to enforce them, and it's then free to use that
information. If that can harm performance - other than by the checks
themselves - that would be very bad, and I don't have any mental model that
would predict that.

On Thu, Apr 2, 2026 at 6:41 PM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Thu, 2 Apr 2026 at 16:02, Mark Hoemmen <mark.hoemmen_at_[hidden]> wrote:
>
>> Jonathan Wakely wrote:
>> > So you can't use contract checks as performance hints
>> > in your code without disabling checks at API boundaries between
>> > untrusted (or less trusted, or less tested) components.
>>
>> My understanding is that the preferred idiom is to perform contract
>> checks first, then use `assume` or analogous features for performance
>> optimization, as in the following example.
>>
>> template<size_t ByteAlignment>
>> void foo(span<float> x)
>> pre(std::is_sufficiently_aligned<ByteAlignment>(x.data())
>> {
>> span x_a(std::assume_aligned<ByteAlignment>(x.data());
>> // ... compute with x_a ...
>> }
>>
>> Is that right?
>>
>>
> My view is that no, it's not right in general. For the reasons given in
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf
>
> And as found by Adrian in the first post in the thread, turning all
> assertions into assumptions can hurt performance as much as it can help.
> You should use assumptions more conservatively, in targeted places where
> profiling has shown that it matters. See also
> https://discourse.llvm.org/t/llvm-assume-blocks-optimization/71609
>
> Not every precondition that you want to check using an assertion is a
> suitable optimization hint. There might be some things that you want to
> assert and assume (separately), but often you'll want just one or the other.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>