[PATCH 2/5] Support Intel SHA512

[Jiang, Haochen]

> I'm afraid I don't understand. How is it not? It uses YMM registers.
> And conceivably there could be EVEX encodings of these (allowing the
> full 32 register set to be used), which I'd then call AVX512-SHA512.
> 
> It's also not possible to potentially express the same thing in
> legacy encodings (unlike e.g. GFNI). Even for SM3, where only 128-
> bit operations are used, that's not possible, as the insns have 3
> inputs (the destination is r/w).

I am actually expressing that to the same thing as GFNI although it does not
has legacy encoding.

Actually, we somehow want to show the evolution from previous SHA. I will
move the entry of them just after the SHA since they are both crypto related
ISAs.

> [...]
> So for a feature check requirement referencing just AVX may be okay. But
> there's not going to be any SHA512 without AVX anyway, for there not
> being any YMM registers without AVX; you wouldn't be able to fill the
> register operands. Hence the extra feature check is redundant (and would
> hence better be omitted).
> 
> As to implying baseline functionality, using AVX (rather than AVX2) makes
> little sense, so even if the feature check remained (note that various
> other extensions, including e.g. AVX-VNNI-INT<n>, don't have such a
> secondary requirement), I'd still be fairly insistent on having the
> base feature named here (and for SM4) be AVX2 (to be in line with other
> similar baseline selections).

I confirmed that AVX in doc here means a state of the whole AVX ISA,
which should include AVX and AVX2. 

I will change the imply of SHA512 and SM4 to AVX2 since it looks much more
reasonable.

Should we also change the imply of SM3 here?

Thx,
Haochen

> 
> Jan