Re: defining 2-operand version of 3-operand insns?

[Greg McGary <greg@mcgary.org>]

"Frank Ch. Eigler" <fche@redhat.com> writes:

> You can define these outside the alias mechanism, by the way.
> Just provide two different insn objects.

I thought I did that via `dni', but as stated before, cgen was
unhappy with the encoding.

> Have you tried
> 	(emit addr dest (f-src1 f-dest) src2)
> instead?

Yes.  CGEN accepts it, but there's no change in the output.

> OTOH, I've only seen (f-FIELD VALUE) construct used with
> literal VALUE arguments.

That appears to be the limitation.

I got this to work by employing a dirty trick.  Fortunately,
the dest and src1 operands are contiguous, so I defined a
new field that encompasses both, called f-dest2, and used
encode/decode magic to propagate:

(df  f-dest2   "dest dup'ed into src1"      () 25 10 UINT
     ((value pc) (add UWI value (sll UWI value (const 5))))
     ((value pc) (srl UWI value 5)))

The decode part is actually unused, since the insn that uses
dest2 has a NO-DIS attribute.

I used a similar dirty-trick to define a subtract immediate
pattern where only an `addi' instruction exists in the machine.
Alongside the normal 16-bit signed immediate field  f-simm16,
I defined f-nimm16 which is a negated version:

(df  f-nimm16  "negated 16-bit immediate"   () 15 16 INT
     ((value pc) (neg HI value))
     ((value pc) (neg HI value)))

Both of these work just the way I want.

Should we endorse or deprecate such abuses? 8^)

Greg