[all-commits] [llvm/llvm-project] 423030: [CIR] Address review on the x86-64 va_arg expansion

[Adam Smith via All-commits]

  Branch: refs/heads/users/adams381/cir-callconv-vaarg-x86-64
  Home:   https://github.com/llvm/llvm-project
  Commit: 423030d98ad4159c0ee3c8bb6a500fc1e4987431
      https://github.com/llvm/llvm-project/commit/423030d98ad4159c0ee3c8bb6a500fc1e4987431
  Author: Adam Smith <adams at nvidia.com>
  Date:   2026-09-15 (Tue, 15 Sep 2026)

  Changed paths:
    M clang/lib/CIR/Dialect/Transforms/TargetLowering/CIRABIRewriteContext.cpp
    M clang/test/CIR/CodeGen/var-arg-aggregate.c
    M clang/test/CIR/CodeGen/var-arg-direct-offset.cpp
    M clang/test/CIR/CodeGen/var-arg-empty.c
    M clang/test/CIR/CodeGen/var-arg-int128.c

  Log Message:
  -----------
  [CIR] Address review on the x86-64 va_arg expansion

rewriteVAArg had grown to 254 lines, with the register arm alone taking
105 of them inside a nested builder callback.  The round-up, the overflow
arm, the register gate, the pair reassembly, the temp copy and the cursor
write-back are now named functions taking a small context struct, and the
48 and 176 register-file bounds sit in one place.

Four fixes come with it.

A va_arg of an empty record yielded a dummy value, which is an alloca and
a load of uninitialized memory.  It now yields the poison the file already
hands to an ignored block argument.

The register slot size came from the integer register count while the
address it described came from whichever area the vector count selected,
so the two disagreed for a fetch needing one register of each class.  Only
one class is ever in play, since a fetch needing both is a coerced pair
that takes the reassembly path, and an assert now says so.  Reachable
fetches are unaffected.

The temp the register arm copies through was allocated inside the arm, and
its address left the arm through the yield.  That worked only because
HoistAllocas moved it somewhere legal afterwards.  Whether a fetch copies
through a temp depends on the classification and the result type rather
than on anything the arm computes, so the decision and the allocation both
happen before the ternary.

A record can need more alignment than any of its types imply: an `aligned`
attribute on a field raises the record without changing the field's type,
and a member record's raised alignment does not survive into the storage
it lowers to.  Only one over-aligned shape was tested, a struct carrying
the attribute on its own declaration.  Four more cover a union, a field
attribute, a member union and a packed record, and all four fail if the
record-layout lookup is removed.

Assisted-by: Cursor / claude-opus-5



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications