On Mon, Sep 28, 2026 at 11:44 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).
I probably had the same questions back then and decided to simply fixup the
INDIRECT_REF case. Maybe AI can help deciphering the current code.
I'd probably start testing by doing just
if (allows_mem
|| ! allows_reg
...
but I do question what we have the else {} case for (is there any test coverage?
a comment should probably point to it!)
> 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.
