On 4/23/23 04:38, Roger Sayle wrote:
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  <ro...@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).
That is pretty cool.  THanks for the explanation.


Thanks again for your help.
Happy to.  Though you might regret asking for it :-)

Tests that now fail, but worked before (5 tests):

xstormy16-sim: gcc.c-torture/execute/memset-2.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
xstormy16-sim: gcc.c-torture/execute/memset-2.c   -O3 -g  (test for excess 
errors)
xstormy16-sim: gcc.c-torture/execute/memset-3.c   -O3 -fomit-frame-pointer 
-funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
errors)
xstormy16-sim: gcc.c-torture/execute/memset-3.c   -O3 -g  (test for excess 
errors)
xstormy16-sim: gcc.c-torture/execute/va-arg-22.c   -O3 -g  (test for excess 
errors)
These started after your xstormy16 changes. Given they're excess errors, they could well be ICEs. I haven't debugged them at all.

jeff

Reply via email to