Question on arithmetic overflow detection support in C2

[Krystal Mok]

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