overflows in SLDivNode

Andreas Woess andreas.woess at oracle.com
Tue Apr 28 09:16:47 UTC 2015

Correct, the idiv instruction has to be guarded by a test on the divisor
being 0 or -1 in case an overflow occurred previously (or always). [1]
Given that, we could indeed have a divideExact that throws on /0 and
MIN_VALUE/-1 and intrinsify it to an idiv without any tests. This method
would always deoptimize the caller on overflow and the Truffle language
implementer have to rewrite the div node on ArithmeticException to a
version not using divideExact (to prevent endless deoptimizations).

One minor problem I see with having such a divideExact method is the
meaning of the word exact: One could, by the name, expect it to throw
when the remainder is non-zero, i.e. the result is truncated and thus
not "exact". But I might be nitpicking here...

[1] It looks like Graal does not do this yet. But let me double-check.

- andreas

On 2015-04-27 20:18, Raffaello Giulietti wrote:
> I'm not an expert in machine code at all. However, my understanding is
> that the x86_64 idiv instruction throws the same exception both when a
> division by 0 occurs and also when the result overflows.
> Since division by 0 in Java already throws an exception, one could
> perhaps process an overflow in the same way in a hypothetical
> intrinsified machine code implementation of divExact().
> Or how does the machine code for a division by 0 look? Is the division
> instruction guarded by a test on the divisor?
> I'm asking the Graal people here...
> On 2015-04-27 19:34, Chris Seaton wrote:
>> Someone writing a Truffle language may look at the ExactMath class, see
>> no exactDivide, and conclude that integer division cannot overflow. Even
>> if our implementation does not give performance gains, it might be good
>> to have it there so that they don’t assume this.
>> Chris
>>> On 27 Apr 2015, at 15:17, Andreas Woess <andreas.woess at oracle.com
>>> <mailto:andreas.woess at oracle.com>> wrote:
>>> However, I don't think we should add a divExact method. We cannot
>>> intrinsify it (the idiv instruction does not set the overflow flag);
>>> for the same reason Java 8 does not have a divideExact. Also, the
>>> utility method cannot specialize (whereas the SLDivNode can), so
>>> having it does not buy us anything.

More information about the graal-dev mailing list