RE: [xstormy16] Add extendhisi2 and zero_extendhisi2 patterns to stormy16.md

["Roger Sayle" <roger@nextmovesoftware.com>]

On 4/33/23, Jeff Law wrote:
> On 4/22/23 14:57, Roger Sayle wrote:
> > Whilst there, I also fixed the instruction lengths and formatting of
> > the zero_extendqihi2 pattern.  Then, mostly for documentation purposes
> > as the 'T' constraint isn't yet implemented, I've added a "and Rx,#255"
> > alternative to zero_extendqihi2 that takes advantage of its efficient
> > instruction encoding.
> >
> > This patch has been tested by building a cross-compiler to
> > xstormy16-elf on x86_64-pc-linux-gnu, and confirming that the new test
> > case passes with "make -k check-gcc".  Ok for mainline?
> >
> >
> > 2023-04-22  Roger Sayle  <roger@nextmovesoftware.com>
> >
> > gcc/ChangeLog
> >          * config/stormy16/stormy16.cc (xstormy16_print_operand): Add %h
> >          format specifier to output high_part register name of SImode reg.
> >          * config/stormy16/stormy16.md (extendhisi2): New define_insn.
> >          (zero_extendqihi2): Fix lengths, consistent formatting and add
> >          "and Rx,#255" alternative, for documentation purposes.
> >          (zero_extendhisi2): New define_insn.
> >
> > gcc/testsuite/ChangeLog
> >          * gcc.target/xstormy16/extendhisi2.c: New test case.
> >          * gcc.target/xstormy16/zextendhisi2.c: Likewise.
> Does the "T" alternative ever match?  AFAICT its constraint check always
> fails:
> 
> > (define_constraint "T"
> >   "@internal"
> >   ;; For Rx; not implemented yet.
> >   (match_test "0"))
> 
> No objections, but just not sure what's going on with that T constraint.

This is an interesting/cool artifact of the xstormy16 architecture/instruction set
that isn't yet (fully) supported in GCC, but much of the infrastructure is in place.
Instructions on xstormy16 are encoded by either one or two 16-bit words.
If an immediate constant is between 0..15, arithmetic instructions can be
encoded in a single word, otherwise they require two words, with a full
16-bit immediate constant in the second word.  The possibly unique feature
of xstormy is an "Rx" addressing mode, that can be used when the destination
register is the same destination as the previous instruction, which by implicitly
encoding DEST, allows 8-bit immediate constants, to be encoded in a single word
instruction.

Handling this dependency between instructions is tricky, with Rx (aka Rpsw) depending
upon the N0..N3 bits in the flags register, and these bits being modified/updated
by almost every instruction.  The 'T' constraint is a placeholder, that currently
always returns false but in theory allows the register allocator to identify/select
this alternative, and the psw_operand attribute on each instruction indicating
how it updates N0..N3 (DEST) bits in the processor status word (PSW).

This feature is particularly useful for zero extension from QI to HI mode.  This
normally requires a shl/shr sequence, but when the register being extended was
modified in the preceding instruction, the single word instruction "and Rx,#255"
can be used.

Currently, for
unsigned char foo(unsigned char x) { return ~x; }
GCC -O2 generates:
foo:    not r2
        shl r2,#8 | shr r2,#8
        ret
but more optimally could use:
foo:    not r2  // Rx now means r2
        and Rx,#255  // shorter than and r2,#255
        ret


I doubt this functionality will be supported by the register allocator and/or scheduler
any time soon, but there's plenty that can be done with "macro instructions", for
example, a hypothetical "*onecmplqi_zexthi" which matches the above RTL,
something  (zero_extend:HI (not:QI (match_operand:QI "register_operand")),
could emit "not %0 | and Rx,#255".

Presumably, the semantics of "Rx" are correctly supported by the xstormy16 simulator?

I hope this helps explain things (as I understand them).
Thanks again for your help.
Roger
--