Bug 25550 - Review .arch directives
Summary: Review .arch directives
Status: NEW
Alias: None
Product: binutils
Classification: Unclassified
Component: gas (show other bugs)
Version: 2.35
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-13 18:10 UTC by H.J. Lu
Modified: 2020-02-19 12:41 UTC (History)
1 user (show)

See Also:
Host:
Target: i386,x86-64
Build:
Last reconfirmed:


Attachments
A patch to document 5 separate non-integer register ISA extension families (839 bytes, patch)
2020-02-19 11:59 UTC, H.J. Lu
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2020-02-13 18:10:20 UTC
We need a way to build an object:

1. Without MMX, but with SSE, VEX and EVEX encodings
2. Without SEE nor MMX, but with VEX and EVEX encodings
3. Without SSE, MMX, AVX, but with EVEX encodings

which is enforced by assembler. ".arch" directives may be used to that.
Comment 1 Jan Beulich 2020-02-14 11:39:41 UTC
However, as pointed out in the mail discussion already, consistent behavior should result (which currently isn't the case):

1. Since .arch generally enables prereqs for the specified ISA extension (like AVX for AVX512F), disabling an extension also should disable everything that it is considered a prereq for.

2. Any ISA extension enabled should be enabled completely. The main anomaly looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking the MMX ISA extension isn't a prereq to the SSE* ones (it's only the registers that are used), which gas also handles this way. A patch was already proposed to address this:

https://sourceware.org/ml/binutils/2020-02/msg00250.html
Comment 2 H.J. Lu 2020-02-14 12:46:58 UTC
(In reply to Jan Beulich from comment #1)
> However, as pointed out in the mail discussion already, consistent behavior
> should result (which currently isn't the case):
> 
> 1. Since .arch generally enables prereqs for the specified ISA extension
> (like AVX for AVX512F), disabling an extension also should disable
> everything that it is considered a prereq for.

Is SSE2 a prerequisite for AVX?

> 2. Any ISA extension enabled should be enabled completely. The main anomaly
> looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking
> the MMX ISA extension isn't a prereq to the SSE* ones (it's only the
> registers that are used), which gas also handles this way.

For view point of assembly codes, enable MMX register without MMX ISA
makes no sense. For example, emms is needed for proper MMX usage.
Comment 3 Jan Beulich 2020-02-14 12:59:52 UTC
(In reply to H.J. Lu from comment #2)
> (In reply to Jan Beulich from comment #1)
> > However, as pointed out in the mail discussion already, consistent behavior
> > should result (which currently isn't the case):
> > 
> > 1. Since .arch generally enables prereqs for the specified ISA extension
> > (like AVX for AVX512F), disabling an extension also should disable
> > everything that it is considered a prereq for.
> 
> Is SSE2 a prerequisite for AVX?

This can be viewed either way, I guess. The history of the ISA extensions suggests it is. But functionally nothing except the XMM registers have any overlap, I think.

> > 2. Any ISA extension enabled should be enabled completely. The main anomaly
> > looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking
> > the MMX ISA extension isn't a prereq to the SSE* ones (it's only the
> > registers that are used), which gas also handles this way.
> 
> For view point of assembly codes, enable MMX register without MMX ISA
> makes no sense. For example, emms is needed for proper MMX usage.

Not necessarily, one can certainly get away without (using 4 FFREEP in a row).
Comment 4 H.J. Lu 2020-02-14 13:02:57 UTC
(In reply to Jan Beulich from comment #3)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Jan Beulich from comment #1)
> > > However, as pointed out in the mail discussion already, consistent behavior
> > > should result (which currently isn't the case):
> > > 
> > > 1. Since .arch generally enables prereqs for the specified ISA extension
> > > (like AVX for AVX512F), disabling an extension also should disable
> > > everything that it is considered a prereq for.
> > 
> > Is SSE2 a prerequisite for AVX?
> 
> This can be viewed either way, I guess. The history of the ISA extensions
> suggests it is. But functionally nothing except the XMM registers have any
> overlap, I think.

Why is AVX a prerequisite for AVX512?

> > > 2. Any ISA extension enabled should be enabled completely. The main anomaly
> > > looks to be SSE/SSE2 insns accessing MMX registers, where strictly speaking
> > > the MMX ISA extension isn't a prereq to the SSE* ones (it's only the
> > > registers that are used), which gas also handles this way.
> > 
> > For view point of assembly codes, enable MMX register without MMX ISA
> > makes no sense. For example, emms is needed for proper MMX usage.
> 
> Not necessarily, one can certainly get away without (using 4 FFREEP in a
> row).

What purpose does it serve?
Comment 5 Jan Beulich 2020-02-14 13:08:53 UTC
(In reply to H.J. Lu from comment #4)
> (In reply to Jan Beulich from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > Is SSE2 a prerequisite for AVX?
> > 
> > This can be viewed either way, I guess. The history of the ISA extensions
> > suggests it is. But functionally nothing except the XMM registers have any
> > overlap, I think.
> 
> Why is AVX a prerequisite for AVX512?

The correlation is largely the same as the one between SSE* and AVX.

> > > For view point of assembly codes, enable MMX register without MMX ISA
> > > makes no sense. For example, emms is needed for proper MMX usage.
> > 
> > Not necessarily, one can certainly get away without (using 4 FFREEP in a
> > row).
> 
> What purpose does it serve?

Well, I don't expect anyone would actively want to use it this way.
Comment 6 H.J. Lu 2020-02-14 13:22:07 UTC
(In reply to Jan Beulich from comment #5)
> (In reply to H.J. Lu from comment #4)
> > (In reply to Jan Beulich from comment #3)
> > > (In reply to H.J. Lu from comment #2)
> > > > Is SSE2 a prerequisite for AVX?
> > > 
> > > This can be viewed either way, I guess. The history of the ISA extensions
> > > suggests it is. But functionally nothing except the XMM registers have any
> > > overlap, I think.
> > 
> > Why is AVX a prerequisite for AVX512?
> 
> The correlation is largely the same as the one between SSE* and AVX.

I agree with you on both counts.  I think treating MMX, SSE, AVX and AVX512
as separate ISA families gives assembler the most flexibility.  Of course,
we need to document whatever behavior we decide.

> > > > For view point of assembly codes, enable MMX register without MMX ISA
> > > > makes no sense. For example, emms is needed for proper MMX usage.
> > > 
> > > Not necessarily, one can certainly get away without (using 4 FFREEP in a
> > > row).
> > 
> > What purpose does it serve?
> 
> Well, I don't expect anyone would actively want to use it this way.

I think it is better to allow MMX register only if MMX ISA is enabled.
Comment 7 H.J. Lu 2020-02-16 15:16:17 UTC
CRC32 is the part of SSE4.2.  But it isn't a vector instruction.
We can add CpuCRC32 to enable CRC32 when SSE4.2 is disabled.
Comment 8 H.J. Lu 2020-02-16 17:07:09 UTC
We can say something like

     In addition to the basic instruction set, the assembler can be told
     to accept various extension mnemonics.  4 separate vector ISA
     extension families can be enabled or disabled independent of each
     other:

        * 'MMX' - MMX instructions.

        * 'SSE' - SSE instructions without MMX registers.

        * 'AVX' - AVX instructions.

        * 'AVX512' - AVX512 instructions.
Comment 9 Jan Beulich 2020-02-18 16:00:05 UTC
(In reply to H.J. Lu from comment #8)
> We can say something like
> 
>      In addition to the basic instruction set, the assembler can be told
>      to accept various extension mnemonics.  4 separate vector ISA
>      extension families can be enabled or disabled independent of each
>      other:
> 
>         * 'MMX' - MMX instructions.
> 
>         * 'SSE' - SSE instructions without MMX registers.

This is not a useful category. The only viable options I see are
- the full set of insns valid with SSE* (including ones accessing MMX registers),
- all insns not touching MMX _state_ (which would permit use of CVTPI2PD with a memory operand, but not use of a similar CVTPI2PS).

In the latter case special care should be taken to at least warn about Intel syntax uses like "CVTPI2PD xmm0, mm0", as from simply looking at such an insn one wouldn't tell it uses a memory operand named "mm0".
Comment 10 H.J. Lu 2020-02-18 16:19:10 UTC
(In reply to Jan Beulich from comment #9)
> (In reply to H.J. Lu from comment #8)
> > We can say something like
> > 
> >      In addition to the basic instruction set, the assembler can be told
> >      to accept various extension mnemonics.  4 separate vector ISA
> >      extension families can be enabled or disabled independent of each
> >      other:
> > 
> >         * 'MMX' - MMX instructions.
> > 
> >         * 'SSE' - SSE instructions without MMX registers.
> 
> This is not a useful category. The only viable options I see are
> - the full set of insns valid with SSE* (including ones accessing MMX
> registers),
> - all insns not touching MMX _state_ (which would permit use of CVTPI2PD
> with a memory operand, but not use of a similar CVTPI2PS).
> 

We need a directive for SSE instructions without MMX registers.
We can give it a different name, something like pure-SSE.
Comment 11 Jan Beulich 2020-02-18 16:35:58 UTC
(In reply to H.J. Lu from comment #10)
> We need a directive for SSE instructions without MMX registers.
> We can give it a different name, something like pure-SSE.

But what practical use would such an option be? You said yourself that anything that can engage MMX state in the CPU also is liable to want/need access to EMMS (or FEMMS), which won't be accessible with just SSE insns permitted.
Comment 12 H.J. Lu 2020-02-18 16:59:25 UTC
(In reply to Jan Beulich from comment #11)
> (In reply to H.J. Lu from comment #10)
> > We need a directive for SSE instructions without MMX registers.
> > We can give it a different name, something like pure-SSE.
> 
> But what practical use would such an option be? You said yourself that
> anything that can engage MMX state in the CPU also is liable to want/need
> access to EMMS (or FEMMS), which won't be accessible with just SSE insns
> permitted.

I want assembler to enforce assembly codes without any access to MMX state.
Comment 13 Jan Beulich 2020-02-19 08:15:26 UTC
(In reply to H.J. Lu from comment #12)
> I want assembler to enforce assembly codes without any access to MMX state.

Well, that's what is described by my 2nd option, but it is (as explained) specifically not sufficient to merely exclude all uses of MMX registers to achieve this.
Comment 14 H.J. Lu 2020-02-19 11:42:05 UTC
(In reply to Jan Beulich from comment #13)
> (In reply to H.J. Lu from comment #12)
> > I want assembler to enforce assembly codes without any access to MMX state.
> 
> Well, that's what is described by my 2nd option, but it is (as explained)
> specifically not sufficient to merely exclude all uses of MMX registers to
> achieve this.

It is no difference from

     if (i.has_regmmx
          || i.tm.base_opcode == 0xf77 /* emms */
          || i.tm.base_opcode == 0xf0e /* femms */)
        x86_feature_2_used |= GNU_PROPERTY_X86_FEATURE_2_MMX;
Comment 15 H.J. Lu 2020-02-19 11:59:35 UTC
Created attachment 12302 [details]
A patch to document 5 separate non-integer register ISA extension families
Comment 16 Jan Beulich 2020-02-19 12:36:12 UTC
(In reply to H.J. Lu from comment #14)
> (In reply to Jan Beulich from comment #13)
> > Well, that's what is described by my 2nd option, but it is (as explained)
> > specifically not sufficient to merely exclude all uses of MMX registers to
> > achieve this.
> 
> It is no difference from
> 
>      if (i.has_regmmx
>           || i.tm.base_opcode == 0xf77 /* emms */
>           || i.tm.base_opcode == 0xf0e /* femms */)
>         x86_feature_2_used |= GNU_PROPERTY_X86_FEATURE_2_MMX;

It is, for the case where no MMX register is used, but MMX state still gets engaged (like CVTPI2PS with a memory operand).
Comment 17 H.J. Lu 2020-02-19 12:41:32 UTC
(In reply to Jan Beulich from comment #16)
> (In reply to H.J. Lu from comment #14)
> > (In reply to Jan Beulich from comment #13)
> > > Well, that's what is described by my 2nd option, but it is (as explained)
> > > specifically not sufficient to merely exclude all uses of MMX registers to
> > > achieve this.
> > 
> > It is no difference from
> > 
> >      if (i.has_regmmx
> >           || i.tm.base_opcode == 0xf77 /* emms */
> >           || i.tm.base_opcode == 0xf0e /* femms */)
> >         x86_feature_2_used |= GNU_PROPERTY_X86_FEATURE_2_MMX;
> 
> It is, for the case where no MMX register is used, but MMX state still gets
> engaged (like CVTPI2PS with a memory operand).

We need to handle these 2 like EMMS:

cvtpi2ps, 2, 0xf2a, None, 2, CpuSSE, Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoAVX, { Qword|Unspecified|BaseIndex|RegMMX, RegXMM }
cvtpi2pd, 2, 0x660f2a, None, 2, CpuSSE2, Modrm|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|NoAVX, { Qword|Unspecified|BaseIndex|RegMMX, RegXMM }