Question on arithmetic overflow detection support in C2
forax at univ-mlv.fr
Tue Jun 19 00:19:17 PDT 2012
I'm not sure to understand why you need a pair of values knowing that
methods like Math.addExact() throws an ArithmeticException if it overflows
so in my opinion, only one value is needed.
I think the easy way is to check if their is a
catch(ArithmeticException) that is
transformed to a goto (the VM already does that) and to generate an add
+ a jump on overflow
for that case.
BTW, I'm very happy and I suppose that Charles (Nutter) and the Jython
team is happy too,
that you guys take a look to that optimization.
On 06/19/2012 06:43 AM, Vladimir Kozlov wrote:
> Vladimir Kozlov wrote:
>> It will be difficult. Almost all data nodes produce only one result and
> I meant only one data edge (not result) is produced.
>> this rule is used in all parts of C2 (from parser to RA). One
>> exception is conditional stores which produce flag and memory state
>> (look in macro.cpp in expand_allocate_common() method). This case
>> handled specially everywhere. And you do need to add overflow and
>> non-overflow pair to BoolTest values.
>> Krystal Mok wrote:
>>> Hi all,
>>> I'm doing some experiments in C2, trying to add support in the IR
>>> for arithmetic overflow detection. Looks like it's quite involved,
>>> Any suggestions on how it could be done would be greatly appreciated
>>> My questions:
>>> 1. The structure of IfNode: does the IR have to be in the form of
>>> Although there's code in idealize_test() (in ifnode.cpp) that checks
>>> if iff->in(1)->is_Bool(), other places seem to assume the sole data
>>> input to If is a Bool, e.g. the transformation in
>>> What if I wanted to add some node type other than Bool as the test
>>> input to If? Something like (If (CheckOverflow expr)), does that
>>> feel right?
>>> 2. The BoolTest kinds, does it feel right to add a pair of kinds for
>>> overflow? Like BoolTest::ovf and BoolTest::noovf. They'll still fit
>>> in the 3-bit encoding.
>>> If this pair is added, then to make it useful, the input to Bool
>>> wouldn't always be Cmp anymore; instead it could be any arithmetic
>>> nodes that modifies the condition flags as a side-effect.
>>> And...that doesn't seem to fit in C2's IR right now, since the only
>>> kind of node that models DEF of the condition flags are the Cmp nodes.
>>> 3. As a quick-n-dirty experiment, I tried not to touch the
>>> machine-independent IR, and instead modify only the ad file to
>>> pattern match the current Java implementation of Match.addExact(int,
>>> int) to make it emit a jo (jump-if-overflow) instruction for
>>> overflow detection, but it failed to compile.
>>> The patch is here: https://gist.github.com/3818aa3acbc78e28e7fa
>>> (Aside: the Ideal graph of the overflow check expression is like this:
>>> This is the state right before matching the matcher rules)
>>> ADLC didn't complain, but the generated jmpAddOverflowNode::Expand()
>>> function had compilation errors, saying:
>>> ../generated/adfiles/ad_x86_64_expand.cpp: In member function
>>> ‘virtual MachNode* jmpAddOverflowNode::Expand(State*, Node_List&,
>>> ../generated/adfiles/ad_x86_64_expand.cpp:5915: error: ‘num8’ was
>>> not declared in this scope
>>> Apparently I was doing something wrong in the ad file, but I don't
>>> quite get what it was.
More information about the hotspot-compiler-dev