On Thu, May 28, 2026 at 01:23:19PM +0200, Uros Bizjak wrote:
> > I thought we want some r <- r, e apx_ndd alternative (r <- r, l is already
> > covered), but then the operands are commutative with % and there is that
> > r <- rje, r alternative. On the other side, the canonical order for
> > CONST_INT operand in addition is that CONST_INT is the second operand, not
> > the first one, so maybe we do want that. But unsure where exactly the
> > actual insn wants the immediate. Though given that the TYPE_LEA
> > "%{nf%} add{<imodesuffix>}\t{%2, %1, %0|%0, %1, %2}" case supposedly
> > assembled as well as that r <- rje, r, maybe it accepts immediates in both
> > spots.
> > But gas rejects the second insn in
> > addq $24, %rax, %rdx
> > addq %rax, $24, %rdx
> > so I really wonder how the r <-> rje, r alternative actually works. This is
> > a mess.
>
> Er, "je" is:
>
> (define_memory_constraint "je"
> "@internal Memory operand for APX EVEX-encoded ADD (i.e. APX NDD/NF)."
> (match_operand 0 "apx_evex_add_memory_operand"))
Oops, sorry.
> the constraint doesn't accept immediates, so everything is OK on this front.
Ah, ok, but then we still lose the r <- r, e APX_NDD && APX_NF variant
(where we don't want a lea, but just %{nf%} add{<imodesuffix>}\t{%2, %1, %0|%0,
%1, %2}
That one worked until now (just claimed that it is lea when it wasn't).
Jakub
