Mulx: Illegal Instruction

[Leif Leonhardy]

Torbjörn Granlund wrote:
> Paul Peet <peetpaul69 at gmail.com> writes:
> 
>   Distro: Arch Linux (x86_64)
>   CPU: Intel Pentium G4400 (Skylake)
>   Kernel: Linux Kernel 4.2.5-1-ARCH
>   GMP-Version: 6.1.0
>   GCC: 5.2.0
>   
>   I discovered this bug while trying to compiling the linux kernel but
>   it ultimately failed.
>   The issue which occured was an SIGILL one. I traced down the issue
>   back to the assembly code and the result was that
>   it was executing a mulx instruction which apparently is invalid here
>   on my cpu (Pentium G4400).
>   A member suggested that it might be an issue with the detection logic in gmp.
>   
>   For more detailed overview of the issue:
>   https://bbs.archlinux.org/viewtopic.php?id=205703
>   
>   Disassembly of the illegal instruction:
>   Dump of assembler code for function __gmpn_sqr_basecase_coreibwl:
>      0x00007ffff7708000 <+0>: cmp    $0x2,%rdx
>      0x00007ffff7708004 <+4>: jae    0x7ffff7708016
>   <__gmpn_sqr_basecase_coreibwl+22>
>      0x00007ffff7708006 <+6>: mov    (%rsi),%rdx
>   => 0x00007ffff7708009 <+9>: mulx   %rdx,%rax,%rdx
> 
> I would expect skylake to come with MULX (which were introduced with
> haswell) as well as ADX (which were introduced with broadwell)..
> 
> Perhaps Intel fused them out in an attempt to make a low-end product
> less attractive.  I'll ask.

None of the Pentium G Skylakes have AVX (just SSE 4.1/4.2) [1], nor
apparently BMI2.

Quoting Intel [2]:

"It is important to understand that a new instruction is supported on a
particular processor only if the corresponding CPUID feature flag is
set.  Applications must not assume support of any instruction set
extension simply based on, for example, checking a CPU model or family
and must instead always check for _all_ the feature CPUID bits of the
instructions being used."

InterestinglyTM, the Spec Update for the Skylake processors [3, PDF
only] lists the following:

------------------------------------------------------------------------
SKD052:  CPUID Incorrectly Reports Bit Manipulation Instructions Support

Problem:  Executing CPUID with EAX = 7 and ECX = 0 may return EBX with
bits [3] and [8] set, incorrectly indicating the presence of BMI1 and
BMI2 instruction set extensions.

Implication:  Attempting to use instructions from the BMI1 or BMI2
instruction set extensions will result in a #UD exception.

Workaround:  It is possible for the BIOS to contain a workaround for
this erratum.

Status:  No fix.  Affects 6th Generation Intel® Pentium® processor
family and Intel® Celeron® processor family.
------------------------------------------------------------------------


So at least for now, configuring with 'ivybridgenoavx' seems to be the
right thing to do.  (Adding in addition '-mno-bmi -mno-bmi2' to CFLAGS
isn't necessary in this case.)


@Paul:  You probably have to recompile a couple of packages with
modified CFLAGS / '-march=...' etc.


-leif

[1] http://ark.intel.com/products/88179

[2]
https://software.intel.com/en-us/articles/how-to-detect-new-instruction-support-in-the-4th-generation-intel-core-processor-family

[3]
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf
(page 30, 11)

> We encountered a similar situation with AVX challenged haswells.
> It will be too much work for us to support a matrix of
> (microarchitectures x fused instructions).  We will handle this new
> world by dropping back to an older microarchitecture where the fused
> instruction exists.  E.g., a skylake without MULX will be treated as an
> ivybridge.