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.
... cases like this (which is how I actually came to notice the issue).
Jan
