Question on arithmetic overflow detection support in C2 (original) (raw)

Krystal Mok rednaxelafx at gmail.com
Tue Jun 19 07:07:35 PDT 2012

Hi John,

Thank you for the suggestion!

There are a couple of things I didn't understand clearly with your suggestion:

In the DivMod example, Div and Mod nodes with the same inputs start out floating separately, and get fused into a single DivMod late in Optimize(). The DivMod node type is a MultiNode with 2 projections, one for the div and the other for the mod. There's special treatment of DivMod in Matcher, and custom logic to match the projections.

If I add a new node type AddIOverflow following the same model, I might get it like this: https://gist.github.com/bdd13666e4796b09f36e This node type would have 2 projections just like DivMod, one for the add, and the other for the overflow condition.

Then there are two questions:

  1. I'd need another new node type, presumably called "CheckAddIOverflow" here, that derives from CmpINode and acts as if it produces condition codes. AddI(a, b) and CheckAddIOverflow(a, b) float separately, just like the DivMod example. They get fused up late in Optimize() into the AddIOverflow shown above. Does this sound right?

  2. With AddIOverflow going into the Matcher, how should I write the match rule in the ad file, to match: If(Bool(Proj(AddIOverflow(a, b)).overflow, ne), labl) ?

Would it look like: match(If cop (AddIOverflow dest src)) ?

If the pair of overflow/non-overflow conditions are in BoolTest and in cmpOp, perhaps I wouldn't need to match the If node, and could just let jmpCon rule handle it as-is. That way I just have to match AddIOverflow itself in the ad file, like DivMod.

Regards, Kris

On Tue, Jun 19, 2012 at 3:55 PM, John Rose <john.r.rose at oracle.com> wrote:

On Jun 18, 2012, at 9:38 PM, Vladimir Kozlov wrote:

will be difficult. Almost all data nodes produce only one result and this rule is used in all parts of C2 (from parser to RA).

Yes; we won't have a good story for producing multiple values from IR nodes. But, for a workaround to this, look at UseDivMod. The idea is to let the IR nodes for the two results float separately, and fuse them when convenient at the end of the compilation. In this pattern, consider paired node types: AddI(a, b): I AddIOverflow(a, b): I It's probably not necessary to change the semantics of Bool. Just do something like this: If(Bool(ne, AddIOverflow(a, b))) The AddIOverflow works like a CmpI, and produces condition codes. There's no need for special ov conditions, IMO. The "magic" for accessing the HW overflow bit can be specified in a AD file match rule that recognizes a Bool and an AddIOverflow next to each other. — John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120619/df3e0a78/attachment.html

More information about the hotspot-compiler-dev mailing list