checkedint call removal
Tofu Ninja via Digitalmars-d
digitalmars-d at puremagic.com
Thu Jul 31 09:38:36 PDT 2014
On Thursday, 31 July 2014 at 10:14:06 UTC, Marc Schütz wrote:
> On Thursday, 31 July 2014 at 08:23:44 UTC, Daniel Murphy wrote:
>> "Daniel Murphy" wrote in message
>> news:lrct2d$1me8$1 at digitalmars.com...
>>
>>> > Wait, what? I thought the whole point of enforce is that it
>>> > will *not*
>>> > be removed by the compiler, no matter what?
>>>
>>> No, the compiler is free to remove it if it can prove it will
>>> never be triggered. eg if the condition is checking a ubyte
>>> < 1000. If the assert in that example is never false, then
>>> the enforce is dead code.
>>
>> Actually, thinking about this some more...
>>
>> In this program the enforce can be removed
>>
>> assert(x < y);
>> enforce(x < y);
>>
>> But not in this one:
>>
>> enforce(x < y);
>> assert(x < y);
>>
>> because the compiler does need to take control flow into
>> account when applying the information in the assert. In this
>> case the assert does not actually give the compiler any new
>> information.
>
> No, if assert means "I promise that x < y where assert() is
> called", then "x < y" also holds when "enforce()" is called,
> because x and y cannot have changed between the two calls.
I think this is the biggest problem with optimizing whilst
removing the check. It seems like if you remove the check and
assume that the check was true then you get really wonky stuff
like checks before the assert being removed.
One solution that would still provide some optimization benefits
is to make the optimizations as if the check is still their.
Meaning that only things after the assert could be optimized
based on the contents of the assert.
I think that is an extension of what Daniel is saying. The assert
optimization needs to take into account control flow, but It
needs to take into account its own control flow as well(even if
the control flow is not actually inserted).
so...
enforce(x);
assert(x);
would not remove the enforce.... because the x would only be
known to be true after the assert because of the check in assert,
even if the check is not added it would optimize as if it was
added.
More information about the Digitalmars-d
mailing list