[fpc-devel] SSE/AVX instruction encodings

J. Gareth Moreton gareth at moreton-family.com
Thu Oct 1 18:03:41 CEST 2020

Hi Torsten,

I've done that already actually, although only to grab the value of the 
ExistsSSEAVX field.  I'm currently testing a new nested function in 

   function CheckSSEAVX: Boolean;
       Result := False;

       if not MemRefInfo(opcode).ExistsSSEAVX then

       { This check also covers MMX instructions that move data to and from
         32-bit and 64-bit registers or memory, since such instructions are
         replicated in SSE2 for use with XMM registers }
       if tx86operand(operands[1]).opsize in [S_B,S_W,S_L,S_Q] then
           opsize := S_NO;

       if (tx86operand(operands[1]).opsize <> S_NO) and 
(operands[1].opr.typ = OPR_REFERENCE) then
           { Memory sizes of 64 bits and under are handled above }

       { If the source operand is larger than the destination (e.g.
         "VCVTTPD2DQ XMM0, YMM1" in Intel notation), use the source 
operand }
       if ((tx86operand(operands[1]).opsize = S_YMM) and 
(tx86operand(operands[2]).opsize = S_XMM)) or
         (tx86operand(operands[1]).opsize = S_ZMM) and 
(tx86operand(operands[2]).opsize = S_XMM) or
         (tx86operand(operands[1]).opsize = S_ZMM) and 
(tx86operand(operands[2]).opsize = S_YMM) then

       { If none of the conditions are met, this function returns False 
and the
         opsize is set to the last operand's opsize }

I've also commented out the individual checks for MOVD, MOVQ, VMOVQ etc 
to see how it handles itself and to simplify the code. "make all" at 
least works successfully and it fixes the bug listed in #37785, but it 
will need extensive testing, lest I break someone's assembly language.

Note that the reason why I've done "(tx86operand(operands[1]).opsize = 
S_YMM) and (tx86operand(operands[2]).opsize = S_XMM)" etc. and not 
something like "(tx86operand(operands[1]).opsize >= S_YMM) and 
(tx86operand(operands[1]).opsize > tx86operand(operands[2]).opsize)" is 
for future safety, since the opsize field doesn't have items in size 
order (plus some entries, like S_BL, don't have a distinct size because 
it's a size conversion) and it's to prevent an unintended side-effect if 
a new entry is added after S_ZMM in the future.

One thing that makes it difficult is that I don't have a processor that 
supports the AVX-512 instruction set, at least I don't think it does 
(Intel Core i7-10750H).

Gareth aka. Kit

P.S. If anyone can see a way to break the above code (before I submit a 
patch), please tell me!

On 01/10/2020 15:52, avx512--- via fpc-devel wrote:
> Hi,
> look at the function "MemRefInfo(aAsmop: TAsmOp)" in "compiler/x86/aasmcpu.pas".
> Torsten
> -----Original-Nachricht-----
> Betreff: [fpc-devel] SSE/AVX instruction encodings
> Datum: 2020-10-01T13:57:05+0200
> Von: "J. Gareth Moreton via fpc-devel" <fpc-devel at lists.freepascal.org>
> An: "FPC developers' list" <fpc-devel at lists.freepascal.org>
> Hi everyone,
> I've decided to take on https://bugs.freepascal.org/view.php?id=37785 -
> I've noticed that the compiler isn't too good at working out the sizes
> of SSE and AVX instructions.  If you look at
> Tx86Instruction.SetInstructionOpsize in compiler/x86/rax86.pas, it
> checks for individual problematic instructions rather than any logical
> flags.  I feel this isn't viable in the long-term (i.e. I really don't
> want to continually add exceptional instructions) and has the code smell
> of something being fundamentally wrong or incomplete with how
> instruction sizes and encodings are determined.
> I'm looking to see if there's a way I can detect the correct size
> logically given the flags.  I figure I'll need to learn a few things
> about AVX512 as well so I don't mess anything up (I've noticed a few
> AVX512 flags to indicate if scalars rather than vectors are being used,
> and wondering if they can be incorporated into the older SSE and AVX
> instructions in x86ins.dat.
> Long story short, I'm going to experiment a bit to see if I can develop
> an algorithm that works and is correct.
> Gareth aka. Kit

This email has been checked for viruses by Avast antivirus software.

More information about the fpc-devel mailing list