RFR(L) 8026844: Various Math functions needs intrinsification

Rickard Bäckman rickard.backman at oracle.com
Tue Oct 22 06:59:21 PDT 2013


new webrev: http://cr.openjdk.java.net/~rbackman/8026844.1/
The diff between webrevs: http://cr.openjdk.java.net/~rbackman/8026844.1.diff/
(Forgot to add x86_32.ad to that one though).

The reason I didn't implement mulexact(reg, mem) was that we didn't have
imull and imulq for (reg, mem). I've added those now.
I also noticed that we never generated *Exact(reg, mem) because of a
problem in Matcher::find_shared. Since the *Exact nodes have two
outputs all inputs of *Exact will be marked as shared. I decided to
only push the *Exact-node for the Result unless only the FlagsProj
is used.


On 10/18, Vladimir Kozlov wrote:
> Rickard,
> is_MathExactOpcode() could be replaced by adding the node to
> DEFINE_CLASS_ID structure as you did with FlagsProj. is_MathExact()
> will be true for all its subclasses.
> Put MathExactNode() constructors together.
> In library_call.cpp can you name Integer version of method with I:
> inline_math_addExactI() to be symmetrical with Long version. And I
> don't think you need separate methods for increment and decrement -
> path flag to add and sub method.
> Why you did not implement mulexact(reg, mem) mach nodes?
> Otherwise it is good.
> Thanks,
> Vladimir
> On 10/18/13 2:34 AM, Rickard Bäckman wrote:
> >Hi, can I get reviews for the following change:
> >
> >This change creates intrinsics for addExact(long, long), subtractExact,
> >negateExact, incrementExact, decrementExact and multiplyExact.
> >
> >The intrinsics are only added on x86 and only 64-bit has the intrinsics
> >for the long-versions. (32-bit only has int-versions).
> >
> >Bug: https://bugs.openjdk.java.net/browse/JDK-8026844
> >Webrev: http://cr.openjdk.java.net/~rbackman/8026844/
> >
> >Thanks
> >/R
> >

More information about the hotspot-compiler-dev mailing list