(original) (raw)

Got the jo instruction emitted now. Thanks Vladimir!

I added a new FlagsProjNode type that derives from ProjNode, and explicitly overrides bottom_type() and ideal_reg() to TypeInt::CC and Op_RegFlags, respectively. That enabled the projection node matching to work.

Current status of the patch is avaiable here:�https://gist.github.com/b24382a3dda090ab63ff

But there are still some unexpected behavior. I was expecting the Bool(... \[ov\]) node to be matched into a cmpOp, and the If node to be matched into a jmpCon; instead, they're actually matched into the unsigned version. Can't figure out what was going on yet.

The IR graph of Math.addExact(int, int),

after Optimize():�http://dl.iteye.com/upload/picture/pic/114606/0e8e47af-729e-36ca-baee-ed15174dd178.png

before matching:�http://dl.iteye.com/upload/picture/pic/114610/05e81e91-ef99-3d9c-a543-12dacb9c2ae4.png

(so far so good)

after matching and GCM:�http://dl.iteye.com/upload/picture/pic/114612/da53b8cf-3ed2-30d2-9cfa-a1a43e94a4c2.png

(oops...got jmpConU instead of the expected jmpCon)

Another problem is that I had to use a fixed register for the "dst" of checkedAddI\_reg and its data result projection. In this case I'm using eax; but any fixed RegI will do.

The cause is stated before: I don't know how to specify the relationship between the "dst" of checkedAddI\_reg and its data result projection, so as to make them use the same register.

If I can fix these two problems, then I'll go back and make a full-fledged intrinsic for Math.addExact(int, int). The way I pattern match the overflow checking logic wouldn't work when Math.addExact(int, int) is inlined into a caller with complex control-flow.

Thanks,

Kris

On Thu, Jun 21, 2012 at 10:07 AM, Vladimir Kozlov <vladimir.kozlov@oracle.com> wrote:

C2 matchs from bottom to top of graph. So first it tries to match If node and failed. In second mail I explained that State for Proj node is incorrect for your case because ideal\_reg() is incorrect:

s->DFA( m->ideal\_reg(), m );

Vladimir