Home Original page

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

H.J. Lu hjl.tools@gmail.com
Thu Feb 13 16:37:00 GMT 2020 
On Thu, Feb 13, 2020 at 8:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 13.02.2020 16:56, H.J. Lu wrote:
> > On Thu, Feb 13, 2020 at 6:52 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> 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
> >
> > We can use it to build a pure AVX512 object.
>
> But that's not something to be achieved by .arch directives. I
> can see the (at least theoretical) usefulness of such a mode,
> but it should be controlled by something other than .arch, much
> like SSE2AVX mode or SSE insn checking modes also can't be
> controlled this way.

I think it is doable.

> Jan
>
> >> anyway? Such a mode is even contrary to -O converting EVEX to
> >> VEX where possible.
> >
> > Well, we should check if AVX is enabled when doing it.
> >
>


-- 
H.J.
More information about the Binutils mailing list