On Mon, Sep 28, 2026 at 11:43 AM Uros Bizjak <[email protected]> wrote: > > On Mon, Sep 28, 2026 at 9:39 AM Richard Biener > <[email protected]> wrote: > > > > 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. > > I based the whole idea on your 2022 patch [1], where the patch > deliberately left the other tcc_reference operands unexplored. Since > my GIMPLE knowledge is limited, my patch just trivially adds some of > them (with the help of AI) to the existing condition (the ones that I > can easily check with the C examples).
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591462.html > Also, I noticed that the current unpatched compiler produces unoptimal code > for: > > int m; > > int foo (void) > { > asm ("mov %%fs, %0" : "=rm" (m)); > > return m; > } > > gcc -O2: > > mov %fs, m(%rip) > movl m(%rip), %eax > ret > > which would really benefit from using a temporary reg. > > Uros.
