<p><br>
On Apr 8, 2013 8:42 AM, "Duncan Sands" <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>> wrote:<br>
><br>
> Hi Cameron,<br>
><br>
><br>
> On 07/04/13 19:42, Cameron McInally wrote:<br>
>><br>
>> On Sun, Apr 7, 2013 at 1:23 PM, Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a><br>
>> <mailto:<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>>> wrote:<br>
>> ...<br>
>><br>
>>     If you want a trap you are going to have to (IMO) output IR<br>
>>     instructions rather than a constant expression.  For example you can output the<br>
>>     equivalent of<br>
>>        if (x == 0)<br>
>>           llvm.trap() // or maybe some special trap routine<br>
>>        y = whatever/x<br>
>>        ... use y ...<br>
>>     rather than the constant expression "whatever/x".  If the optimizers can prove<br>
>>     that x is never zero then this will be sunk back into a constant expression (if<br>
>>     "whatever" is a constant expression).<br>
>><br>
>><br>
>> Ah, that's super interesting. I'll have to give it some more thought. Thanks for<br>
>> this, Duncan.<br>
>><br>
>> My knee-jerk reaction is that emulating hardware behaviour in software should be<br>
>> avoided. At least in this specific case.<br>
><br>
><br>
> I reckon it shouldn't be too hard to teach the code generators to turn this IR<br>
> sequence into "y = target-divide whatever/x" on targets for which dividing by 0<br>
> traps in a satisfactory way, so it turns into something efficient.<br>
><br>
If the application is safety related, then the if (x == 0) should be there in the source code anyway. <br>
If it happens to be able to optimize it into the div instruction at target lowering, then it could do it then.<br>
If a target cpu does not do the div trap then the target lowering would at least maintain the safety at the expense of an extra branch.</p>
<p>James.<br>
</p>