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