Disable sse/avx

[Red_prig]

Is there a compiler option that can prevent the generation of sse/avx instructions using xmm/ymm ? And can this be done for a separate module? (x86_64)

[marcov]

Afaik SSE2 is part of the architecture definition of the x86_64 architecture. All but the very oldest (2002,2003,-HAMMER) x86_64 machines also have SSE3.

Win64 binaries using SSE2 is pretty much standard.

AVX afaik won't be used unless you instruct the compiler to.

[Kays]

Is there a compiler option that can prevent the generation of sse/avx instructions using xmm/ymm ? […]

AFAIK, there are some development efforts, but the FPC does currently not use SSE/AVX instructions (except data moves). Could you show some code that led to insertion of “undesired” instructions? The System Ⅴ ABI (which the FPC [largely/completely] complies with on some targets) can use xmm registers for parameter passing, but, you know, this does not really constitute serious use of SIMD instructions.

Afaik SSE2 is part of the architecture definition of the x86_64 architecture. […]

Nope, it’s not. SSE2 literally stands for Streaming SIMD Extensions 2. You can query availability of SSE2 via cpuid. However, there are no commercially available x86‑64 processors that do not support SSE2, hence you can almost certainly infer x86‑64 ⇒ SSE2 available.

[Red_prig]

I'm just talking about sending data using movdqu/movdqa. I have a specific context where registers need to be saved before calling a function, so I wondered if I could simplify this by not using extension registers.

[Red_prig]

Code: Pascal  [Select][+][-]

1. C:\git\fpPS4\sys\test\kern_jit2_ctx.pas:307  begin
2. 00000001000BC7C0 55                       push rbp
3. 00000001000BC7C1 4889E5                   mov rbp,rsp
4. 00000001000BC7C4 488D642480               lea rsp,[rsp-$80]
5. 00000001000BC7C9 48897DE8                 mov [rbp-$18],rdi
6. 00000001000BC7CD 488975F8                 mov [rbp-$08],rsi
7. 00000001000BC7D1 488955F0                 mov [rbp-$10],rdx
8. 00000001000BC7D5 488B45F8                 mov rax,[rbp-$08]
9. 00000001000BC7D9 F30F6F00                 movdqu xmm0,[rax]
10. C:\git\fpPS4\sys\test\kern_jit2_ctx.pas:307  begin
11. 00000001000BC7DD 660F7F45B0               movdqa [rbp-$50],xmm0
12. C:\git\fpPS4\sys\test\kern_jit2_ctx.pas:308  if (dst=nil) then Exit;
13. 00000001000BC7E2 48837DF000               cmp qword ptr [rbp-$10],$00
14. 00000001000BC7E7 7460                     jz +$60    # $00000001000BC849 ADD_FORWARD_POINT+137 kern_jit2_ctx.pas:319
15. C:\git\fpPS4\sys\test\kern_jit2_ctx.pas:310  node.dst:=dst;
16. 00000001000BC7E9 488B45F0                 mov rax,[rbp-$10]
17. 00000001000BC7ED 488945D0                 mov [rbp-$30],rax
18. C:\git\fpPS4\sys\test\kern_jit2_ctx.pas:311  Result:=forward_set.Find(@node);
19. 00000001000BC7F1 488D55C0                 lea rdx,[rbp-$40]
20. 00000001000BC7F5 488B4DE8                 mov rcx,[rbp-$18]
21. 00000001000BC7F9 E8F2F6FFFF               call -$0000090E    # $00000001000BBEF0 FIND g_node_splay.pas:222
22. 00000001000BC7FE 488945E0                 mov [rbp-$20],rax
23.  

[marcov]

Is there a compiler option that can prevent the generation of sse/avx instructions using xmm/ymm ? […]

AFAIK, there are some development efforts, but the FPC does currently not use SSE/AVX instructions (except data moves).

This is incorrect. It uses SSE2 for FPU on Win64, as per Windows 64-bit ABI.

Afaik SSE2 is part of the architecture definition of the x86_64 architecture. […]

Nope, it’s not. SSE2 literally stands for Streaming SIMD Extensions 2. You can query availability of SSE2 via cpuid. However, there are no commercially available x86‑64 processors that do not support SSE2, hence you can almost certainly infer x86‑64 ⇒ SSE2 available.

Extensions to 32-bit x86 for sure. But just look at the register paragraph of the original x86_64 ABI document: https://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf

3.2.1 Registers and the Stack Frame
The AMD64 architecture provides 16 general purpose 64-bit registers. In addition
the architecture provides 16 SSE registers, each 128 bits wide and 8 x87 floating
point registers, each 80 bits wide. Each of the x87 floating point registers may be
referred to in MMX/3DNow! mode as a 64-bit register. All of these registers are
global to all procedures active for a given thread.

[Kays]

You can:

• Familiarize with the ABI. Avoid data types that match the “SSE class”, e. g.

Code: Pascal  [Select][+][-]

1. function f(x: double): double;

becomes

Code: Pascal  [Select][+][-]

1. function f(var x: double): double;

[/li]

• Disable the {$calling register} calling convention.
• Set {$FPUtype x87} if you suffer from Windoze Syndrome.

[…] look at the register paragraph of the original x86_64 ABI document:  […]

[…] The AMD64 architecture provides […]. In addition the architecture provides 16 SSE registers […]

My reading is this concerns AMD64. There’s a bit of a “war ”going on between AMD and Intel, who’s got the authoritative power (because they can’t share). Apparently AMD64 says it’s a must.

[Red_prig]

It seems that the only option for me is to carefully monitor the sizes of data types, oh sad.

[PascalDragon]

You can:

• Disable the {$calling register} calling convention.
• Set {$FPUtype x87} if you suffer from Windoze Syndrome.

Both these solutions are not supported on x86_64.

[…] look at the register paragraph of the original x86_64 ABI document:  […]

[…] The AMD64 architecture provides […]. In addition the architecture provides 16 SSE registers […]

My reading is this concerns AMD64. There’s a bit of a “war ”going on between AMD and Intel, who’s got the authoritative power (because they can’t share). Apparently AMD64 says it’s a must.

Intel licensed the AMD64 extensions from AMD, so the base implementation which in this case refers to the presence of SSE and SSE2 is the same between the two.

[marcov]

You can:

• Familiarize with the ABI.
  

Don't have to look further than the title, it states it governs LP64 and ILP32 architectures. Win64 however is LLP64.

Probably some legacy architectures from fruit infested OSes do this, but really, they want you to shell out an arm (and a leg) for an ARM now.
[/list]

[Kays]

[…] Both these solutions are not supported on x86_64. […]

What’s the reason? My x86‑64 computer can execute x87 instructions and stack-based calling conventions are possible, too.

Don't have to look further than the title, it states it governs LP64 and ILP32 architectures. […]

I can’t follow. Which title? How does it relate to the topic, to banning SSE/AVX instructions?

[marcov]

[…] Both these solutions are not supported on x86_64. […]

What’s the reason? My x86‑64 computer can execute x87 instructions and stack-based calling conventions are possible, too.

Outside non x86(_32) systems, you generally follow the system ABI. Only x86 32-bit is somewhat tolerant of mixing calling conventions, mostly for historical reasons (and even then only if you don't consider e.g. cross language exceptions).

Don't have to look further than the title, it states it governs LP64 and ILP32 architectures. […]

I can’t follow. Which title? How does it relate to the topic, to banning SSE/AVX instructions?

The title of the document that you link.  The relation is, again, that SSE is part of the AMD64/x86_64 ABI. Even if it is more on some systems than others (like win64)

I assume that if the OP used a system with an ABI that used x87 for floating point, he would have wondered about SSE use in the first place.

[PascalDragon]

[…] Both these solutions are not supported on x86_64. […]

What’s the reason? My x86‑64 computer can execute x87 instructions and stack-based calling conventions are possible, too.

The register calling convention is only supported on i386 and m68k, for other platforms FPC simply uses the platform ABI of which there usually exists only one (for compatibility reasons register is simply an alias to cdecl then).

While the SysV ABI defines support for long double and FPC handles that correctly, Win64 does not and the x87 is to be not considered available on that platform. And even on SysV platforms SSE is the preferred method, because it doesn't require to handle a completely separate stack (however the math related functions in the RTL do work with the x87 on the SysV platforms to provide the full precision).