Request for reviews (XL): 7119644: Increase superword's vector size up to 256 bits (original) (raw)

Christian Thalinger christian.thalinger at oracle.com
Mon Jun 4 12:38:43 PDT 2012

On Jun 4, 2012, at 11:56 AM, Vladimir Kozlov wrote:

Christian Thalinger wrote:

On Jun 2, 2012, at 8:19 PM, Vladimir Kozlov wrote:

Most changes after latest Tom's review were done in superword.cpp and added regression tests. I think I nailed down latest issues I had with superword code. The changes pass all testing I did. Please, review it (same web link). src/cpu/sparc/vm/sparc.ad: It seems Repl8Breghelper (and probably the other helpers too) are only used once and so is encrepl8b. Can't we just move the code into the instruct itself using the MacroAssembler? But I guess you want to keep this change small given it's already big. I keep it because of regLtostkD() usage but it looks like it is also used only by Repl instructions. I will inline them and use masm instructions instead. src/cpu/x86/vm/x86.ad: + regdef XMM0 ( SOC, SOC, OpRegF, 0, xmm0->asVMReg()); + regdef XMM0b( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()); + regdef XMM0c( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()); + regdef XMM0d( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()->next()); + regdef XMM0e( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()->next()->next()); + regdef XMM0f( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()->next()->next()->next()); + regdef XMM0g( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()->next()->next()->next()->next()); + regdef XMM0h( SOC, SOC, OpRegF, 0, xmm0->asVMReg()->next()->next()->next()->next()->next()->next()->next()); Maybe we should use a macro for this block instead of replicating it 16 times. Yes, it is annoying but ADLC parser does not support complex macros.

Ok.

src/share/vm/opto/superword.cpp: 276 // Second, removed already constructed packs of the same type. Typo "removed". Fixed. + // Reconect loads back to upperinsertpt. Typo. Fixed. I didn't check all the tests but I guess they are okay. About OpVec names, how about using the bit size as suffix: OpVec32, OpVec64, OpVec128, OpVec256? Because most of the time when we speak about vectors it's about bit sizes like "7119644: Increase superword's vector size up to 256 bits". ADLC parser does not work with such names. It distinguish registers by last letter.

Grrr. Stupid parser.

-- Chris

Thanks, Vladimir

-- Chris Thanks, Vladimir

On 4/3/12 10:03 AM, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/7119644/webrev

7119644: Increase superword's vector size up to 256 bits Increase superword's vector size up to 256-bits for YMM AVX registers on x86. Added generation of different vector sizes for different types of arrays in the same loop. Allow to generate small (4 bytes) vectors for loops which were unrolled small number of iterations. Add new C2 types for vectors and rework VectorNode implementation. Used MachTypeNode as base node for vector mach nodes to keep vector type. Moved XMM registers definition and vector instructions into one file x86.ad (have to rename eRegI to rRegI in x8632.ad). Tested with full CTW, NSK, C2 regression tests, JPRT and added new test. Thanks, Vladimir

More information about the hotspot-compiler-dev mailing list