On Wed, Sep 25, 2024 at 3:55 PM Jan Beulich <jbeul...@suse.com> wrote:
>
> On 25.09.2024 09:38, Hongtao Liu wrote:
> > On Wed, Sep 25, 2024 at 2:56 PM Jan Beulich <jbeul...@suse.com> wrote:
> >>
> >> Commit a79d13a01f8c ("i386: Fix aes/vaes patterns [PR114576]") correctly
> >> said "..., but we need to emit {evex} prefix in the assembly if AES ISA
> >> is not enabled". Yet it did so only for the TARGET_AES insns. Going from
> >> the alternative chosen in the TARGET_VAES insns is wrong for two
> >> reasons:
> >> - if, with AES disabled, the latter alternative was chosen despite no
> >> "high" XMM register nor any eGPR in use, gas would still pick the AES
> > w/o EVEX SSE REG or EGPR, the first alternative will always be
> > matched(alternative 0).
> > That is how it works(match from left to right).
>
> Well, if that's guaranteed to always be the case, then ...
>
> >> (VEX) encoding when no {evex} pseudo-prefix is in use (which is
> >> against - as stated by the description of said commit - AES presently
> >> not being considered a prereq of VAES in gcc);
> >
> >> - if AES is (also) enabled, EVEX encoding would needlessly be forced.
> > So it's more like an optimization that use VEX encoding when AES is enabled?
>
> ... in a way it's an optimization, yes. I can adjust the description
> accordingly. However, it's not _just_ an optimization, it also is a
> fix for compilation (really: assembly) failing in ...
>
> >> ---
> >> As an aside - {evex} (and other) pseudo-prefixes would better be avoided
> >> anyway whenever possible, as those are getting in the way of code
> >> putting in place macro overrides for certain insns: gas 2.43 rejects
> >> such bogus placement of pseudo-prefixes.
So it sounds like a walkaround in GCC to avoid the gas bug?
In general, I'm ok for the patch since we already did that in
TARGET_AES patterns.
27060(define_insn "aesenc"
27061 [(set (match_operand:V2DI 0 "register_operand" "=x,x,v")
27062 (unspec:V2DI [(match_operand:V2DI 1 "register_operand"
"0,x,v")
27063 (match_operand:V2DI 2 "vector_operand"
"xja,xjm,vm")]
27064 UNSPEC_AESENC))]
27065 "TARGET_AES || (TARGET_VAES && TARGET_AVX512VL)"
27066 "@
27067 aesenc\t{%2, %0|%0, %2}
27068 * return TARGET_AES ? \"vaesenc\t{%2, %1, %0|%0, %1, %2}\" :
\"%{evex%} vaesenc\t{%2, %1, %0|%0, %1, %2}\";
27069 vaesenc\t{%2, %1, %0|%0, %1, %2}"
27070 [(set_attr "isa" "noavx,avx,vaes_avx512vl")
>
> ... cases like this (which is how I actually came to notice the issue).
>
> Jan
--
BR,
Hongtao
