Question on arithmetic overflow detection support in C2

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jun 18 21:43:25 PDT 2012


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


More information about the hotspot-compiler-dev mailing list