The article makes no mention of optimisation use cases. In case anyone already knows off the top of their heads and before I start digging for the answer, is part of the intent here for these to inform the optimiser stages, perhaps similarly to what the if (!(some_condition)) { __builtin_unreachable(); } idiom can achieve?

▲

leni536 2 hours ago | parent | next [-]

That is not a primary goal. There was a discussion about "assume" semantics, but that is not one of the standardized contract evaluation semantics.

▲

throwaway17_17 8 hours ago | parent | prev | next [-]

Allegedly the pre and post conditions, in varying degrees of certainty according to the evaluation semantics selected, are propagated to the optimization passes of gcc and llvm. However, I haven’t seen any detailed blog posts or summaries of the effectiveness or reliability of this feature. Sorry it’s not a lot of info, but it was what I knew off hand based on previous reading.

▲

account42 7 hours ago | parent [-]

But for the most use you'd specifcially want them used for optimizations when they are NOT being evaluated as that's the build where perf matters.

	▲	tsukikage 7 hours ago \| parent [-]
		...yup, looks like there's no way to get the optimisation benefit in "ignore" mode, which is the only mode that doesn't explicitly compile the runtime checks: https://godbolt.org/z/KTx1Pc3aa compare codegen for test3 (the pattern that would be useful) vs test4 (the best we actually have)

▲

i2talics 6 hours ago | parent | prev [-]

I don't get the impression that these are meant to influence optimization at all.