This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: fix AVX* dependencies of ".arch .nosse*"


On 13.02.2020 15:17, H.J. Lu wrote:
> On Thu, Feb 13, 2020 at 5:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 13.02.2020 12:50, H.J. Lu wrote:
>>> On Thu, Feb 13, 2020 at 1:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> Since ".arch .avx*" enables SSE*, disabling SSE* should also disable
>>>> AVX*. Together with 7deea9aad866 ('x86: fix SSE4a dependencies of
>>>> ".arch .nosse*"') I think this makes clear that the whole .arch logic
>>>> needs an overhaul, such that the mechanism to enable features implies
>>>> the reverse operation when disabling any, without having to modify two
>>>> places. Arm64's approach may be worthwhile to consider cloning.
>>>>
>>>> Note that while commit 1848e567343e ("Update x86 CPU_XXX_FLAGS
>>>> handling") introducing the testcase which needs fixing here explicitly
>>>> says "Don't disable AVX nor AVX512 when disabling SSE", I don't see why
>>>> this would be. Furthermore it also says "Don't disable AVX512 when
>>>> disabling AVX", which too has been undone meanwhile (commit 89199bb5a027
>>>> ["ix86: Disable AVX512F when disabling AVX2"], PR gas/24359). The only
>>>> sensible (consistent) alternative therefore would be to avoid enabling
>>>> SSE* with ".arch .avx*", like is done for SSE* wrt MMX (in turn leading
>>>> to inconsistencies with SSE insns accessing MMX registers).
>>>>
>>>
>>> The intended usages are to build an object:
>>>
>>> 1. Without MMX, but with SSE, AVX and AVX512.
>>> 2. Without SEE nor MMX, but with AVX and AVX512.
>>> 3. Without SSE, MMX, AVX, but with AVX512.
>>>
>>> enforced by assembler.
>>
>> For one - this isn't spelled out anywhere in the docs. And then it's
>> also counter-intuitive. Plus your point 3 isn't true afaict, as per
>> commit 89199bb5a027 mentioned above.
> 
> We should revisit it.

What is the point of a mode like what you outline in 3 above
anyway? Such a mode is even contrary to -O converting EVEX to
VEX where possible.

Jan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]