Question on arithmetic overflow detection support in C2 (original) (raw)
Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jun 18 21:43:25 PDT 2012
- Previous message: Question on arithmetic overflow detection support in C2
- Next message: Question on arithmetic overflow detection support in C2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 expandallocatecommon() 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 Ifproj->If->Bool->Cmp Although there's code in idealizetest() (in ifnode.cpp) that checks if iff->in(1)->isBool(), other places seem to assume the sole data input to If is a Bool, e.g. the transformation in Matcher::findshared(). 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/adx8664expand.cpp: In member function ‘virtual MachNode* jmpAddOverflowNode::Expand(State*, NodeList&, Node*)’: ../generated/adfiles/adx8664expand.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
- Previous message: Question on arithmetic overflow detection support in C2
- Next message: Question on arithmetic overflow detection support in C2
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the hotspot-compiler-dev mailing list