Hi John,<div><br></div><div>Thank you for the suggestion!</div><div><br></div><div>There are a couple of things I didn&#39;t understand clearly with your suggestion:</div><div><br></div><div>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&#39;s special treatment of DivMod in Matcher, and custom logic to match the projections.</div>
<div><br></div><div>If I add a new node type AddIOverflow following the same model, I might get it like this:</div><div><a href="https://gist.github.com/bdd13666e4796b09f36e">https://gist.github.com/bdd13666e4796b09f36e</a>
</div><div>This node type would have 2 projections just like DivMod, one for the add, and the other for the overflow condition.</div><div><br></div><div>Then there are two questions:</div><div><br></div><div>1. I&#39;d need another new node type,presumablycalled &quot;CheckAddIOverflow&quot; 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?</div>
<div><br></div><div>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) ?</div><div><br></div><div>Would it look like: match(If cop (AddIOverflow dest src)) ?</div>
<div><br></div><div>If the pair of overflow/non-overflow conditions are in BoolTest and in cmpOp, perhaps I wouldn&#39;t need to match the If node, and could just let jmpCon rule handle it as-is.</div><div>That way I just have to matchAddIOverflow itself in the ad file, like DivMod.</div>
<div><br></div><div>Regards,</div><div>Kris</div>
<div><br><div class="gmail_quote">On Tue, Jun 19, 2012 at 3:55 PM, John Rose <span dir="ltr">&lt;<a href="mailto:john.r.rose@oracle.com" target="_blank">john.r.rose@oracle.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word"><div><div><div>On Jun 18, 2012, at 9:38 PM, Vladimir Kozlov wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">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).</span></blockquote>

</div><br></div><div>Yes; we won&#39;t have a good story for producing multiple values from IR nodes.</div><div><br></div><div>But, for a workaround to this, look atUseDivMod. 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.</div>

<div><br></div><div>In this pattern, consider paired node types:</div><div> AddI(a, b): I</div><div> AddIOverflow(a, b): I</div><div><br></div><div>It&#39;s probably not necessary to change the semantics of Bool. Just do something like this:</div>

<div> If(Bool(ne, AddIOverflow(a, b)))</div><div><br></div><div>The AddIOverflow works like a CmpI, and produces condition codes. There&#39;s no need for special ov conditions, IMO.</div><div><br></div><div>The &quot;magic&quot; 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.</div>

<span><font color="#888888"><div><br></div><div> John</div></font></span></div></blockquote></div><br></div>