我正在 JIT 编译器中动态生成一些操作码，我正在寻找操作码对齐的指南。
1）我已经阅读了通过在调用后添加 nops 来简要“推荐”对齐的评论
2）我还阅读了有关使用 nop 优化并行性序列的信息。
3）我读过操作对齐对“缓存”性能有好处
通常这些评论不提供任何支持性参考。阅读博客或评论说“这样做这样那样是个好主意”是一回事，但实际编写一个编译器来实现特定的操作序列并在线实现大多数材料，尤其是博客，这是另一回事用于实际应用。所以我相信自己找出问题（反汇编等，看看现实世界的应用程序做了什么）。这是我需要一些外部信息的一种情况。
我注意到编译器通常会在之前的任何指令序列之后立即启动一个奇字节指令。因此，在大多数情况下，编译器不会特别注意。我在这里或那里看到“nop”，但通常似乎 nop 被谨慎使用，如果有的话。操作码对齐有多重要？您能否提供我可以实际用于实施的案例的参考资料？谢谢。
我理解字对齐，这使得 cpu 在将整数读入寄存器时只需要读取一次。
但是对于“双”是否需要8 字节对齐（假设是 32 位系统）？有什么好处？如果用于存储“double”的空间只是 4 字节对齐会发生什么？
我在尝试编组此结构时遇到异常
[StructLayout(LayoutKind.Explicit, Pack = 1)]
public struct Data
{
[MarshalAs(UnmanagedType.ByValArray, SizeConst = 4, ArraySubType = UnmanagedType.U1)]
[FieldOffset(0x1)]
public byte[] a2;
}
它说“无法从程序集“WTF，Version=1.0.0.0，Culture=neutral，PublicKeyToken=null”加载类型“WTF.Data”，因为它在偏移量 1 处包含一个对象字段，该对象字段未正确对齐或被非对象场。”
当我将偏移量 1 更改为 0 或 4 时，一切正常。我究竟做错了什么？
谢谢
我原以为 8 位 AVR 平台不需要任何对齐。但是，我在LLVM commit 中发现了以下评论：
以前的数据布局在处理原子时引起了问题。
例如，加载小于 16 位对齐的 16 位值是非法的。
这会更改数据布局，以便所有类型至少以它们自己的宽度对齐。
不幸的是，这个提交的原作者也不确定这是否正确：
自从我最初从 SourceForge 导入旧的 SVN 存储库以来，大部分对齐内容都没有受到影响。我没有处理过太多，所以我的知识很差。
最安全的假设是，如果某件事看起来是故意的，那可能不是;P
（8 位）AVR 上的对齐故事究竟是什么？
我有一个由7个__m256值组成的结构,它在内存中以32字节对齐的方式存储.
typedef struct
{
__m256 xl,xh;
__m256 yl,yh;
__m256 zl,zh;
__m256i co;
} bloxset8_t;
我通过使用posix_memalign()动态分配数据的函数或使用(aligned(32))静态分配数据的属性来实现32字节对齐.
对齐很好,但是当我使用两个指向这样的结构的指针,并将它们作为memcpy()的目标和源传递时,编译器决定使用它__memcpy_avx_unaligned()来复制.
我如何强制clang使用对齐的avx memcpy函数,我认为这是更快的变体？
操作系统:Ubuntu 16.04.3 LTS,Clang:3.8.0-2ubuntu4.
UPDATE
仅在复制两个或多个结构时调用__memcpy_avx_unaligned().当只复制一个时,clang会发出14个vmovup指令.
该函数mkl_malloc类似于malloc但有一个额外的alignment参数。这是原型：
void* mkl_malloc (size_t alloc_size, int alignment);
我注意到具有不同值的不同性能alignment。除了反复试验之外，是否有一种规范的或记录在案的有条理的方法来决定 的最佳值alignment？即正在使用的处理器、正在调用的函数、正在执行的操作等。
这个问题广泛适用于任何使用 MKL 的人，所以我很惊讶它不在参考手册中。
更新：我已经尝试过mkl_sparse_spmm并且没有注意到将对齐设置为 2 的幂（最多 1024 字节）的性能有显着差异，之后性能往往会下降。我使用的是英特尔至强 E5-2683。
最近我一直在研究 MIPS 指令集，当时我遇到了两个在其他指令集中没有见过的不寻常指令。
我环顾四周，想找到一个关于指令到底做什么的合理解释，但我所能弄清楚的是，它们在某种程度上与未对齐的内存访问有关。
例如，维基百科说：
MIPS I 要求所有内存访问与其自然字边界对齐，否则会发出异常信号。为了支持有效的未对齐存储器访问，存在以“左”或“右”为后缀的加载/存储字指令。
但没有进一步详细说明这实际上意味着什么。
我能找到的最接近正确解释的是约翰·卢米斯博士的网站：
通过使用一对特殊指令，可以仅在两条指令中加载或存储未对齐的字和双字。对于加载，LWL 指令与 LWR 指令配对。加载指令从对齐字中读取左侧或右侧字节（寄存器的左侧或右侧），并将它们合并到目标寄存器的正确字节中。
但这对我来说似乎仍然只是故事的一半，我很难弄清楚确切的细节。即我正在努力理解哪些地址的哪些字节将被移动到哪里。
那么这些指令到底有什么作用呢？
对于下面的 C 代码，来自Compiler Explorer 的GCC x86-64 10.2发出我在下面进一步粘贴的程序集。
一个指令是subq $40, %rsp。问题是，为什么减去 40 个字节%rsp不会使堆栈未对齐？我的理解是：
call foo，堆栈是 16 字节对齐的；call foo 在堆栈上放置一个 8 字节的返回地址，因此堆栈未对齐；pushq %rbpatfoo的 start 在堆栈上又放置了 8 个字节，因此它再次对齐了 16 个字节；subq $40, %rsp。结果，减少%rsp40个字节一定会破坏对齐吗？显然，就保持堆栈对齐而言，GCC 发出了有效的程序集，所以我一定遗漏了一些东西。
（我尝试用 CLANG 替换 GCC，并且 CLANG 发出了subq $48, %rsp- 正如我直觉所期望的那样。）
那么，我在 GCC 生成的程序集中缺少什么？它如何保持堆栈 16 字节对齐？
int bar(int i) { return i; }
int foo(int p0, int …例如，联合的默认对齐方式如下：
union{
uint32_t v4;
__uint128_t v6;
}ip;
//in memory
//aaaa
//bbbbbbbbbbbbbbbb
但我想让工会正确对齐：
// aaaa
//bbbbbbbbbbbbbbbb
是否有可能在 C 中实现这一点？
根据cppreference，硬件可能要求 an 引用的对象atomic_ref<T>比其他T对象具有更严格的对齐方式，并且 an 上的操作是否atomic_ref是无锁的可以取决于引用对象的对齐方式。
为什么只需要引用的对象具有atomic_ref适当的对齐方式，而std::atomic似乎没有强加这一要求？