[Bug gas/25550] Review .arch directives

2020-02-19 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #17 from H.J. Lu  ---
(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 }

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-19 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #16 from Jan Beulich  ---
(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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-19 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #15 from H.J. Lu  ---
Created attachment 12302
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12302&action=edit
A patch to document 5 separate non-integer register ISA extension families

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-19 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #14 from H.J. Lu  ---
(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;

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-19 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #13 from Jan Beulich  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #12 from H.J. Lu  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-18 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #11 from Jan Beulich  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-18 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #10 from H.J. Lu  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-18 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #9 from Jan Beulich  ---
(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".

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-16 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #8 from H.J. Lu  ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-16 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #7 from H.J. Lu  ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #6 from H.J. Lu  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #5 from Jan Beulich  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #4 from H.J. Lu  ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #3 from Jan Beulich  ---
(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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread hjl.tools at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

--- Comment #2 from H.J. Lu  ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/25550] Review .arch directives

2020-02-14 Thread jbeulich at suse dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=25550

Jan Beulich  changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #1 from Jan Beulich  ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.