On Sun, Sep 27, 2026 at 9:11 PM Uros Bizjak <[email protected]> wrote:
>
> For an output operand whose constraint allows both a register and
> memory (e.g. "=rm"), expand_asm_stmt only binds the operand directly
> to the address of its underlying storage when the operand's value is
> a bare, non-ADDR_EXPR-based MEM_REF or a plain, memory-resident DECL.
> Every other lvalue -- most commonly a struct/union member, an array
> element, or a complex number's real/imaginary part -- is instead
> always routed through a fresh pseudo register that gets copied to the
> real destination in a separate insn after the asm, even though
> nothing about the constraint requires it.
>
> Extend the set of output values eligible for direct addressing to
> also cover COMPONENT_REF (except through a bit-field, which is not
> byte-addressable and still needs the existing register-based
> read-modify-write handling), ARRAY_REF, ARRAY_RANGE_REF, REALPART_EXPR
> and IMAGPART_EXPR.
At least the comment needs updating, but I also wonder why we need the else {}
and whether we can more easily put a condition on that with the if case being
seemingly the more "default" handling?
Also the DECL_P handling would need to apply to the MEM_REF && ADDR_EXPR
case (not sure what the DECL_P handling is about - this code really
lacks comments...).
And I'd like to see using REFERENCE_CLASS_P (val) && (... exclusions ...) rather
than enumerating parts of it that are OK.
>
> Assisted-by: Claude Sonnet 5
>
> PR target/124209
>
> gcc/ChangeLog:
>
> * cfgexpand.cc (expand_asm_stmt): Also bind an output operand
> directly to the address of its storage when its value is a
> COMPONENT_REF (of a non-bit-field), ARRAY_REF, ARRAY_RANGE_REF,
> REALPART_EXPR, or IMAGPART_EXPR and the constraint allows memory.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr124209-1.c: New test.
> * gcc.target/i386/pr124209-2.c: New test.
> * gcc.target/i386/pr124209-3.c: New test.
> * gcc.target/i386/pr124209-4.c: New test.
> * gcc.target/i386/pr124209-5.c: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> OK for trunk?
>
> Uros.