[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8086087: aarch64: add support for 64 bit vectors
From:       Vladimir Kozlov <vladimir.kozlov () oracle ! com>
Date:       2015-06-24 18:58:04
Message-ID: 558AFDBC.1080705 () oracle ! com
[Download RAW message or body]

 > And should the changeset then be based on hs-comp and pushed to hs-comp?

Yes

On 6/24/15 11:53 AM, Edward Nevill wrote:
> On Wed, 2015-06-24 at 09:57 -0700, Vladimir Kozlov wrote:
> > Hi, Ed
> > 
> > I am worried about 32 bit vectors. There could be conflict somewhere in RA since \
> > min_vector_size will not match minimum vector register VecD size.
> > 
> > Can you split these changes to have separate changesets? One is support VecD (64 \
> > bit) and an other 32bit vectors. If some testing will show problems we can check \
> > which changes caused it more precisely.
> 
> Hi Vladimir,
> 
> Thanks for the review. I am generally happy that putting 32 bit values in 64 bit \
> registers is OK. I initially did the 64 bit registers by putting them in 128 bit \
> registers. 
> That worked OK, but there were 2 problems.
> 
> First when a register was spilled I had to spill 128 bits since I did not know the \
> size at the point of the spill. 
> The second problem was with scalar reduction when doing an add across the vector, \
> rather than a parallel vector operation. In this case it would get the wrong result \
> if the top 64 bits were non zero. 
> This is why I generated a separate 64 bit vectorisation.
> 
> With 32 bit, spilling 64 bits instead of 32 bits does not matter, and scalar \
> reduction operations do not exist for 32 bit (the minimum is 2I). 
> I will do as you suggest, and split it into two webrevs.
> 
> > 
> > And this should be reviewed on compiler mailing list instead of runtime.
> 
> And should the changeset then be based on hs-comp and pushed to hs-comp?
> 
> All the best,
> Ed.
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]