RFR(M): 8244504: C2: refactor counted loop code in preparation for long counted loop

Roland Westrelin rwestrel at redhat.com
Mon May 25 09:22:43 UTC 2020


> I really like your asserts that
> test the “fiat type” against the “physics” of the node being
> created; I mean those that say “type doesn’t match”.
> Would it make sense to add more such asserts on the
> other branches?  You’d need a work-alike for the Value
> method of MaxINode for all the other cases, so (sigh)
> maybe it’s too much to squeeze into this work.  The
> lack of good asserts here feels like tech. debt, though.
> Would you mind filing a suitable bug, if you agree with
> me?

Do I understand right that the new bug would be: to provide
CMoveINode::Value() and CMoveLNode::Value() in the case where the input
condition follows the pattern of min/max and then add asserts to
GraphKit::build_min_max(), so essentially the integer interval logic I
gave up on?

> Perhaps the right answer is to move the GraphKit
> functions (one more time) onto polymorphic factory
> methods MaxNode::make and MinNode::make, styled
> like LoadNode::make.

Sure but there's no MinNode, only a MaxNode:

class MinINode : public MaxNode {

Should MaxNode be renamed to MinMaxNode? There's not much in MaxNode so
I suppose its body could be cloned to introduce a MinNode too.

Roland.



More information about the hotspot-compiler-dev mailing list