Question on arithmetic overflow detection support in C2

[Rémi Forax]

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.

cheers,
Rémi

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.
>>
>> Vladimir
>>
>> 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, 
>>> though.
>>> 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
>>> If_proj->If->Bool->Cmp
>>>
>>> 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 
>>> Matcher::find_shared().
>>>
>>> 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:
>>> http://dl.iteye.com/upload/picture/pic/114476/674e0a78-5515-3da3-8ea6-6eedbeb32f8e.png 
>>>
>>> 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&, 
>>> Node*)’:
>>> ../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.
>>>
>>> Regards,
>>> Kris