SuperWord optimization

[Chuck Rasbold]

The last I knew, the thing holding up SuperWord was a resource issue.
But that was several months ago and I don't have any more recent
information.

As for the double_quadword function in x86_32.ad, it looks to me like
the fp_signmask_pool is set up such that the extra buffer space for
alignment adjustments is at the beginning of the pool, not the end.
I think it will work reliably as coded. I can see how your first
instinct would be to put it at the end, though, as you suggest.

-- Chuck

On Wed, Dec 24, 2008 at 1:13 PM, James Walsh
<groundskeeperwiley at yahoo.com> wrote:
> 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
>
>
>
>
>