On Thu, May 28, 2026 at 1:35 PM Jakub Jelinek <[email protected]> wrote: > > 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).
You are right. Let me think about this some more. Thanks, Uros.
