SuperWord optimization

[James Walsh]

I found that definition file after I posted the list.  It's going to take a while for
me to wrap my head around hotspot.  Is work on
SuperWord stalled
because of a fundamental problem with the code or is
it a warm body issue?
I'm interested in getting it into a working state.  I hope no one minds me asking
a lot of questions like the following:

While perusing the repository for SSE code I noticed this code in a couple
places, like x86_32.ad, to speed up neg/abs:

static jlong* double_quadword(jlong *adr, jlong lo, jlong hi) {
    jlong *operand = (jlong*)(((long)adr)&((long)(~0xF)));
    operand[0] = lo;
    operand[1] = hi;
    return operand;
}

While this will certainly align operand to a 16byte boundary doesn't it run the risk
of backing the pointer up too far and modifying the wrong address?  Shouldn't
adr be advanced 15 bytes and then have the logical AND applied to align operand
to the first 16byte aligned memory address that starts at or after adr?

Thanks for the quick response and happy holidays.





----- Original Message ----
From: Chuck Rasbold <rasbold at google.com>
To: hotspot-dev at openjdk.java.net
Sent: Wednesday, December 24, 2008 12:21:36 PM
Subject: Re: SuperWord optimization

You are looking in the wrong spot.  The match rules for the server
compiler are in src/cpu/x86/vm/x86*.ad. There you will see match rules
for some double arithmetic operations, but not float or int, for
example.

Without the appropriate match rule, the superword transformation will
reject an operation as unimplemented. Operations which are implemented
but do not have the necessary vector inputs will be reported as
unprofitable.

Remember that superword is a work in progress, and one that is
stalled, at that. There are bugs, as well as unimplemented features,
and as you play with it, you'll run into a little of both.

-- Chuck