Carry pointee alignment on struct copies through pointers and refs by TurkeyMan · Pull Request #5297 · ldc-developers/ldc

TurkeyMan · 2026-10-04T15:46:56Z

Struct assignment and struct zero/static initialisation emit llvm.memcpy/llvm.memset with alignment 1. Wherever LLVM can't see where a pointer came from (anything reached through a pointer, slice or ref), every struct copy is treated as potentially unaligned. On strict-alignment targets (e.g. -mtriple=armv5te-none-eabi -mattr=+strict-align) each copy then lowers to a run of ldrb/strb.

This PR makes DLValue record the alignment its pointer is guaranteed to have, defaulting to 1 (unknown), and sets it only where it follows from the pointer's type:

*p, p[i], slice[i]
ref parameters, ref returns, ref locals
this in struct methods

Each of these takes the pointee type's alignment (DtoAlignment(T), so align(1) struct stays at 1 and align(16) struct gets 16). That's the assumption LDC already makes for every scalar load and store through such pointers. Struct copies use the recorded alignment of each side separately (DtoMemCpy now takes a destination and a source alignment), and zero/static initialisation uses the destination's.

dst = src;   // ref S8 dst, ref S8 src
before: call void @llvm.memcpy.p0.p0.i64(ptr align 1 %dst, ptr align 1 %src, i64 16, i1 false)
after:  call void @llvm.memcpy.p0.p0.i64(ptr align 8 %dst, ptr align 8 %src, i64 16, i1 false)

Not covered here: field addresses (s.f, obj.f) and static array elements stay at 1. Their alignment depends on the containing aggregate's alignment and the field offset (MinAlign(base, offset)), and doing that properly means scalar loads and stores should honour it too. Today they always assume the ABI alignment, so a uint field in an align(1) struct is loaded with align 4. I'll do that as a follow-up. That follow-up depends on dlang/dmd#23966: UnionExp emplaces RealExp/ComplexExp into storage aligned to 8 while real needs 16 on x86_64 posix, which an earlier version of this change (#5279) tripped over in the self-hosted build.

Tested with the new tests/codegen/struct_copy_alignment.d and the lit suite. I also built ldc2 with the patched compiler and compiled Phobos' std/stdio.d unittests with it using the CI flags, the step where #5279 failed.

TurkeyMan · 2026-10-04T16:35:22Z

This patch begins a more comprehensive take on #5279, which handles a key edge cases with proper alignment tracking. LDC has a serious case of forgetting alignment throughout the flow. There's another one after this which similarly treads some other territory.

kinke · 2026-10-05T14:08:14Z

Thanks, that looks better - and storing the alignment in the DLValue makes sense to me.

That follow-up depends on dlang/dmd#23966

Cool, thx for tracking down and fixing that one.

kinke · 2026-10-05T14:12:08Z

    const auto minAlignment =
        std::min(DtoAlignment(val->type), static_cast<unsigned>(alignment));
-    DtoMemCpy(copy, lval, DtoConstSize_t(minSize), minAlignment);
+    DtoMemCpy(copy, lval, DtoConstSize_t(minSize), minAlignment, minAlignment);


alignment is the destination alignment, val's (new) the source one - no need for minAlignment anymore due to the split alignments now.

kinke · 2026-10-05T14:23:18Z

                                     "made to.");
-      return new DLValue(type, getIrValue(vd));
+      return new DLValue(type, getIrValue(vd),
+                         vd->isReference() ? DtoAlignment(type) : 1);


DtoAlignment(type) should be fine for non-refs too, propagating the alignment of the alloca.

kinke · 2026-10-05T14:24:48Z

        src = indexVThis(ad, thisptr);
      }
      if (depth > 1) {
+        const unsigned ptrAlign = getABITypeAlign(getOpaquePtrType());


IIRC, we use target.ptrsize as pointer alignment in other places already.

kinke · 2026-10-05T14:28:26Z

  if (retValIsLVal) {
-    return new DLValue(resulttype, retllval);
+    return new DLValue(resulttype, retllval,
+                       tf->isRef() ? DtoAlignment(resulttype) : 1);


DtoAlignment(resulttype) should be fine for non-refs too (in which case - retValIsLVal - the lvalue has been allocated by the caller on its stack, and that alloca has the type alignment).

retllval can be in-place construction's sret, for a field which may be align(1). I have a follow-up patch coming which works through a broader set of cases though, and removes this again with that.

kinke · 2026-10-05T14:36:28Z

      LLValue *v = p->func()->thisArg;
-      result = new DLValue(e->type, v);
+      const bool isStruct = e->type->toBasetype()->ty == TY::Tstruct;
+      result = new DLValue(e->type, v, isStruct ? DtoAlignment(e->type) : 1);


For classes, it's the ClassDeclaration::alignsize IIRC.

For classes this lvalue is the stack slot holding this, so it's pointer-aligned. alignsize applies to field accesses through the reference; that comes in the follow-up I mentioned above, and it needs dmd #23966... which was my next question; how do we make a change to LDC which depends on a DMD update?

kinke · 2026-10-05T14:41:57Z

        LLValue *initsym = getIrAggr(sd)->getInitSymbol();
        assert(dstMem->getType() == initsym->getType());
-        DtoMemCpy(DtoType(e->type), dstMem, initsym);
+        DtoMemCpy(DtoType(e->type), dstMem, initsym, false, dstAlign);


The init symbol's alignment is the type's.

kinke · 2026-10-05T14:43:38Z

  static DLValue *emitStructLiteral(StructLiteralExp *e,
-                                    LLValue *dstMem = nullptr) {
+                                    LLValue *dstMem = nullptr,
+                                    unsigned dstAlign = 1) {


Please no default value here, this is an internal helper called twice, so the call sites should take care of passing an alignment.

Struct assignment and struct zero/static initialisation emitted llvm.memcpy/llvm.memset with alignment 1, so LLVM had to treat every struct copy as potentially unaligned whenever it could not see where the pointer came from. On strict-alignment targets that lowers each copy to byte loads and stores. DLValue now records the alignment its pointer is guaranteed to have, defaulting to 1 (unknown). Lvalues formed by dereferencing a pointer (*p, p[i], slice[i]), ref returns, ref locals and the `this` of struct methods take the pointee type's alignment, which LDC already assumes for every scalar load and store through such pointers. Parameters and init symbols take their type's alignment, as their storage is allocated for it. Struct copies and zero-initialisations use the recorded alignment of each side. Field addresses and static array elements stay at 1 for now; their alignment depends on the containing aggregate's alignment and the field offset.

TurkeyMan · 2026-10-06T15:03:57Z

Fixed most of those things, 2 should stay as they are until the follow-up. How do we update DMD though? As soon as the alignments all flow properly, DMD reveals that bug.

TurkeyMan force-pushed the lvalue-alignment branch from 1cfe028 to 46b0d49 Compare October 4, 2026 15:47

TurkeyMan mentioned this pull request Oct 5, 2026

Carry the D type alignment on struct copy/init memcpy and memset #5279

Closed

kinke reviewed Oct 5, 2026

View reviewed changes

TurkeyMan force-pushed the lvalue-alignment branch from 46b0d49 to 1dc79c8 Compare October 6, 2026 14:17

Navigation Menu

Uh oh!

Carry pointee alignment on struct copies through pointers and refs - #5297

Carry pointee alignment on struct copies through pointers and refs#5297
TurkeyMan wants to merge 1 commit into
ldc-developers:masterfrom
TurkeyMan:lvalue-alignment

TurkeyMan commented Oct 4, 2026 •

edited

Loading

Uh oh!

TurkeyMan commented Oct 4, 2026

Uh oh!

kinke commented Oct 5, 2026

Uh oh!

kinke Oct 5, 2026 •

edited

Loading

Uh oh!

kinke Oct 5, 2026

Uh oh!

kinke Oct 5, 2026

Uh oh!

kinke Oct 5, 2026

Uh oh!

TurkeyMan Oct 6, 2026

Uh oh!

kinke Oct 5, 2026

Uh oh!

TurkeyMan Oct 6, 2026

Uh oh!

kinke Oct 5, 2026

Uh oh!

kinke Oct 5, 2026

Uh oh!

TurkeyMan commented Oct 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

TurkeyMan commented Oct 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TurkeyMan commented Oct 4, 2026

Uh oh!

kinke commented Oct 5, 2026

Uh oh!

kinke Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TurkeyMan commented Oct 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

TurkeyMan commented Oct 4, 2026 •

edited

Loading

kinke Oct 5, 2026 •

edited

Loading