Comment by tsukikage

4 days ago

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?

5 comments

tsukikage

Reply
throwaway17_17  4 days ago

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  4 days ago

    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  4 days ago

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

leni536  4 days ago

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