Long multiplication and BigInteger.mulAdd on x86_32

[Tom Rodriguez]

On Feb 1, 2010, at 5:00 PM, John Rose wrote:

> On Feb 1, 2010, at 2:01 PM, Tom Rodriguez wrote:
> 
>> The predicates are ugly but we don't currently have a better mechanism.  The cleaner way this could be expressed would be:
>> 
>> predicate(phase->type(n->in(1))->higher_equals(TypeLong::UINT));
>> 
>> but the Matcher doesn't capture the type table from the last phase of GVN.  The reason we need that is that bottom_type for the AndL doesn't return the narrow type that results from the use of a constant.  It returns the worst case type TypeLong::LONG.  Only the type table captures the improved type that we computed though iter GVN.  If we captured the type table we'd also need to deal with having both old and new nodes in the graph simultaneously which wouldn't be a huge deal but it does point at a potential problem with the predicate approach.  Depending on the graph shape n->in(1) and n->in(2) might already be machine nodes and their Opcode won't be the ideal opcode we're looking for.  I think in most interesting cases the predicate will work correctly though.  It's only if there are multiple users of in(1) or in(2) that it might fail to trigger.  Anyway, I think the predicates are fine for this purpose.
> 
> 
> My first thought also was "why don't we use types for such predicates?"  It would be much more robust that way.  Your explanation of why not is correct.
> 
> There's a marginally better way:  Use a type predicate on the RHS of the AndL node:
>  predicate(n->in(1)->in(2)->bottom_type()->higher_equals(TypeLong::UINT));
> 
> That way we get the optimization for (x & 0xFFFFFFFFl) and also (x & 0xFF) and similar variants.

It will already get those since 0xff & 0xFFFFFFFF00000000LL == 0.

tom

> 
> -- John