Hello!
> This patch is about to support Intel Key Locker extension.
>
> Key Locker provides a mechanism to encrypt and decrypt data with an AES
key without having access to the raw key value.
>
> For more details, please refer to
https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-specification.pdf
.
>
> Bootstrap ok, regression test on i386/x86 backend is ok.
>
> OK for master?
@@ -1414,6 +1418,13 @@ enum reg_class
FP_TOP_REG, FP_SECOND_REG, /* %st(0) %st(1) */
FLOAT_REGS,
SSE_FIRST_REG,
+ SSE_SECOND_REG,
+ SSE_THIRD_REG,
+ SSE_FOURTH_REG,
+ SSE_FIFTH_REG,
+ SSE_SIXTH_REG,
+ SSE_SEVENTH_REG,
+ SSE_EIGHTH_REG,
NO_REX_SSE_REGS,
SSE_REGS,
ALL_SSE_REGS,
@@ -1474,6 +1485,13 @@ enum reg_class
"FP_TOP_REG", "FP_SECOND_REG", \
"FLOAT_REGS", \
"SSE_FIRST_REG", \
+ "SSE_SECOND_REG", \
+ "SSE_THIRD_REG", \
+ "SSE_FOURTH_REG", \
+ "SSE_FIFTH_REG", \
+ "SSE_SIXTH_REG", \
+ "SSE_SEVENTH_REG", \
+ "SSE_EIGHTH_REG", \
"NO_REX_SSE_REGS", \
"SSE_REGS", \
"ALL_SSE_REGS", \
@@ -1513,6 +1531,13 @@ enum reg_class
{ 0x200, 0x0, 0x0 }, /* FP_SECOND_REG */ \
{ 0xff00, 0x0, 0x0 }, /* FLOAT_REGS */ \
{ 0x100000, 0x0, 0x0 }, /* SSE_FIRST_REG */ \
+ { 0x200000, 0x0, 0x0 }, /* SSE_SECOND_REG */ \
+ { 0x400000, 0x0, 0x0 }, /* SSE_THIRD_REG */ \
+ { 0x800000, 0x0, 0x0 }, /* SSE_FOURTH_REG */ \
+ { 0x1000000, 0x0, 0x0 }, /* SSE_FIFTH_REG */ \
+ { 0x2000000, 0x0, 0x0 }, /* SSE_SIXTH_REG*/ \
+ { 0x4000000, 0x0, 0x0 }, /* SSE_SEVENTH_REG */ \
+ { 0x8000000, 0x0, 0x0 }, /* SSE_EIGHTH_REG */ \
{ 0xff00000, 0x0, 0x0 }, /* NO_REX_SSE_REGS */ \
{ 0xff00000, 0xff000, 0x0 }, /* SSE_REGS */ \
{ 0xff00000, 0xfffff000, 0xf }, /* ALL_SSE_REGS */ \
IIRC, adding a new regclass is O(n^2), so it should be avoided. I
think that the new patterns should follow the same path as vzeroall
and vzeroupper patterns, where we emit the pattern with explicit hard
regs.
BTW: We do have SSE_FIRST_REG class, but this class was added to solve
some reload problems in the past by marking %xmm0 as likely spilled.
Uros.
