[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases

2020-10-17 Thread macro--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||ma...@linux-mips.org
   Target Milestone|--- |11.0
   Assignee|unassigned at gcc dot gnu.org  |ma...@linux-mips.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-10-17

[Bug target/58901] vax bootstrap fails on subreg reload

2020-12-05 Thread macro--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901

Maciej W. Rozycki  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ma...@linux-mips.org
 Resolution|--- |FIXED
 CC||ma...@linux-mips.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #9 from Maciej W. Rozycki  ---
Fixed as per the commit message automatically entered.

[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases

2020-12-05 Thread macro--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294

--- Comment #4 from Maciej W. Rozycki  ---
Conversion complete.

[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases

2020-12-06 Thread macro--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294

Maciej W. Rozycki  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Maciej W. Rozycki  ---
Do actually close the bug as previously intended.

[Bug target/98683] New: Non-canonical compare produced with the VAX backend

2021-01-14 Thread macro--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98683

Bug ID: 98683
   Summary: Non-canonical compare produced with the VAX backend
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ma...@linux-mips.org
CC: ma...@linux-mips.org
  Target Milestone: ---
Target: vax-*-netbsdelf

Due to how operands are presented to the `cbranch*' patterns a
non-canonical compare operation might be produced with reload that has
an immediate in its first input operand (and a non-immediate second input
operand, although forms with two immediate inputs have been also
observed).

This can be reproduced with the existing 2422-1.c test case and the
`-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-functions' options, a set from the usual ones used with
regression testing:

(jump_insn 549 550 556 99 (set (pc)
(if_then_else (ge (const_int 0 [0])
(reg:SI 10 %r10 [orig:188 _138 ] [188]))
(label_ref:SI 707)
(pc))) ".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27
521 {*cbranchsi4_ccn}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 707)

which gets split to:

(insn 1959 550 1960 99 (set (reg:CCN 16 %psl)
(compare:CCN (const_int 0 [0])
(reg:SI 10 %r10 [orig:188 _138 ] [188])))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 6 {*cmpsi_ccn}
 (nil))
(jump_insn 1960 1959 556 99 (set (pc)
(if_then_else (ge (reg:CCN 16 %psl)
(const_int 0 [0]))
(label_ref 707)
(pc))) ".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27
535 {*branch_ccn}
 (int_list:REG_BR_PROB 118111604 (nil))
 -> 707)

and ultimately leads to:

#(insn 1959 550 1960 (set (reg:CCN 16 %psl)
#(compare:CCN (const_int 0 [0])
#(reg:SI 10 %r10 [orig:188 _138 ] [188])))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 6 {*cmpsi_ccn}
# (nil))
cmpl $0,%r10# 1959  [c=6]  *cmpsi_ccn/1
#(jump_insn 1960 1959 556 (set (pc)
#(if_then_else (ge (reg:CCN 16 %psl)
#(const_int 0 [0]))
#(label_ref 707)
#(pc)))
".../gcc/testsuite/gcc.c-torture/execute/2422-1.c":21:27 535 {*branch_ccn}
# (expr_list:REG_DEAD (reg:CCN 16 %psl)
#(int_list:REG_BR_PROB 118111604 (nil)))
# -> 707)
jgeq .L73   # 1960  [c=26]  *branch_ccn

As observed here this is handled by the backend just fine, however causes
the less optimal CMPL instruction to be produced rather than TSTL that
has an implicit immediate zero second operand, which could be used if the
inputs were swapped.  This applies to both integer and FP operations.

Currently canonicalization requires that an immediate input operand to
to the compare operation has to come as the second one, however there is
no such requirement for the `cbranch*' patterns, so the fix would have to
be made in the backend, in the relevant splitters, presumably by swapping
the operands and using the reverse branch if an immediate is presented
as the first input operand.

Requiring the first input operand to `cbranch*' to be non-immediate by
means of a predicate results in yet worse code being produced as any
immediate used is then moved to a register by reload, so this would best
be avoided.