TIL about LLVM's ExpandInlineAsm via https://discourse.llvm.org/t/rfc-constant-time-coding-support/87781/37 (@lenary) and I'm more than a little horrified.

[pervognsen@mastodon.social]

The ultimate reductio ad absurdum would be if we start putting machine code bytes in inline asm blocks only for compilers to eventually start "helpfully" disassembling them to perform intrinsic substitutions.

[lenary@types.pl]

@pervognsen Nothing was sacred. It's now more sacred than it was. Though I think AMDGPU? wants to read (but not modify) the string for scheduling hints/annotations.

[pervognsen@mastodon.social]

@lenary Yeah, found the comments on that in the proposed LangRef changes. It's good that this is at least getting nailed down.

[pkhuong@discuss.systems]

@pervognsen can't be too far… i've already had to do that when clang cleverly detected that my inline asm wasn't supported by the -march on the build line… sometimes I just don't want *the compiler* to use fancy stuff, even though it's available.

[zwarich@hachyderm.io]

@pervognsen @lenary There must be some cursed linker out there that inspects machine code bytes to make decisions rather than purely using relocations.

[joe@f.duriansoftware.com]

@zwarich @pervognsen @lenary how about a rosetta-like jit that doesn't change ISAs but just messes with the instructions executed by the host architecture

[zwarich@hachyderm.io]

@joe @pervognsen @lenary This is related to my craziest idea for a technically “memory safe” language. You’re allowed to do arbitrary native code execution from unsafe memory accesses, but it kicks you into a dynamically binary translated environment with runtime checks that only lets you return to executing “normal” code if all of your modifications to memory were type-safe.

[lenary@types.pl]

@zwarich @pervognsen let me introduce you to RISC-V Linker Relaxations, which both inspect and modify machine code bytes to change the sequence to better ones (they still use relocations)

[zwarich@hachyderm.io]

@lenary @pervognsen AArch64 linkers do similar things (e.g. NOPing out parts of multibyte sequences that compress when the displacement is small). Maybe RISC-V has some more interesting variants of this, though.

[lenary@types.pl]

@pervognsen I don't have data to back this up but I presume this exact inline asm string in the x86 callback was in a core header/library somewhere, called from a hot loop, and this made a specific benchmark faster on a machine that had a better core than the header presumed.

[lenary@types.pl]

@zwarich @pervognsen nop-ing is fine compared to relaxation. AArch64 doesn't have variable-width instructions, and doesn't delete instructions during relaxation (shuffling everything afterwards)

[lenary@types.pl]

@zwarich @pervognsen risc-v will do things like rewrite registers in instructions, delete instructions, rewrite them with a smaller variant, etc etc etc. Now remember that alignment needs to be preserved and enjoy your headache.

[siguza@infosec.space]

@pervognsen I was literally about to ask "what if I did .4byte ...?"