[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
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/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Maciej W. Rozycki from comment #4) > Conversion complete. Great. The Bountysource campaign closes the moment you close this bug report. Then every supporter can vote whether they accept the solution.
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 --- Comment #3 from CVS Commits --- The master branch has been updated by Maciej W. Rozycki : https://gcc.gnu.org/g:4f47fca1d0fc2c6efef791d6dd115abd9d221733 commit r11-5797-g4f47fca1d0fc2c6efef791d6dd115abd9d221733 Author: Maciej W. Rozycki Date: Sat Dec 5 18:26:27 2020 + PR target/95294: VAX: Add test cases for MODE_CC representation gcc/testsuite/ PR target/95294 * gcc.target/vax/cmpelim-eq-adddf.c: New test. * gcc.target/vax/cmpelim-eq-addhi.c: New test. * gcc.target/vax/cmpelim-eq-addqi.c: New test. * gcc.target/vax/cmpelim-eq-addsf.c: New test. * gcc.target/vax/cmpelim-eq-addsi.c: New test. * gcc.target/vax/cmpelim-eq-andhi.c: New test. * gcc.target/vax/cmpelim-eq-andqi.c: New test. * gcc.target/vax/cmpelim-eq-andsi.c: New test. * gcc.target/vax/cmpelim-eq-ashlsi.c: New test. * gcc.target/vax/cmpelim-eq-ashrsi.c: New test. * gcc.target/vax/cmpelim-eq-divdf.c: New test. * gcc.target/vax/cmpelim-eq-divhi.c: New test. * gcc.target/vax/cmpelim-eq-divqi.c: New test. * gcc.target/vax/cmpelim-eq-divsf.c: New test. * gcc.target/vax/cmpelim-eq-divsi.c: New test. * gcc.target/vax/cmpelim-eq-extendhisi.c: New test. * gcc.target/vax/cmpelim-eq-extendqisi.c: New test. * gcc.target/vax/cmpelim-eq-extvsi.c: New test. * gcc.target/vax/cmpelim-eq-extzvsi.c: New test. * gcc.target/vax/cmpelim-eq-fixdfhi.c: New test. * gcc.target/vax/cmpelim-eq-fixdfqi.c: New test. * gcc.target/vax/cmpelim-eq-fixdfsi.c: New test. * gcc.target/vax/cmpelim-eq-fixsfhi.c: New test. * gcc.target/vax/cmpelim-eq-fixsfqi.c: New test. * gcc.target/vax/cmpelim-eq-fixsfsi.c: New test. * gcc.target/vax/cmpelim-eq-floatsisf.c: New test. * gcc.target/vax/cmpelim-eq-insvsi.c: New test. * gcc.target/vax/cmpelim-eq-iorhi.c: New test. * gcc.target/vax/cmpelim-eq-iorqi.c: New test. * gcc.target/vax/cmpelim-eq-iorsi.c: New test. * gcc.target/vax/cmpelim-eq-mova.c: New test. * gcc.target/vax/cmpelim-eq-movdf.c: New test. * gcc.target/vax/cmpelim-eq-movhi.c: New test. * gcc.target/vax/cmpelim-eq-movqi.c: New test. * gcc.target/vax/cmpelim-eq-movsf.c: New test. * gcc.target/vax/cmpelim-eq-movsi.c: New test. * gcc.target/vax/cmpelim-eq-muldf.c: New test. * gcc.target/vax/cmpelim-eq-mulhi.c: New test. * gcc.target/vax/cmpelim-eq-mulqi.c: New test. * gcc.target/vax/cmpelim-eq-mulsf.c: New test. * gcc.target/vax/cmpelim-eq-mulsi.c: New test. * gcc.target/vax/cmpelim-eq-nothi.c: New test. * gcc.target/vax/cmpelim-eq-notqi.c: New test. * gcc.target/vax/cmpelim-eq-notsi.c: New test. * gcc.target/vax/cmpelim-eq-rotlsi.c: New test. * gcc.target/vax/cmpelim-eq-rotrsi.c: New test. * gcc.target/vax/cmpelim-eq-subdf.c: New test. * gcc.target/vax/cmpelim-eq-subhi.c: New test. * gcc.target/vax/cmpelim-eq-subqi.c: New test. * gcc.target/vax/cmpelim-eq-subsf.c: New test. * gcc.target/vax/cmpelim-eq-subsi.c: New test. * gcc.target/vax/cmpelim-eq-truncdfsf.c: New test. * gcc.target/vax/cmpelim-eq-trunchiqi.c: New test. * gcc.target/vax/cmpelim-eq-truncsihi.c: New test. * gcc.target/vax/cmpelim-eq-truncsiqi.c: New test. * gcc.target/vax/cmpelim-eq-zextendhisi.c: New test. * gcc.target/vax/cmpelim-eq-zextendqihi.c: New test. * gcc.target/vax/cmpelim-eq-zextendqisi.c: New test. * gcc.target/vax/cmpelim-le-adddf.c: New test. * gcc.target/vax/cmpelim-le-addhi.c: New test. * gcc.target/vax/cmpelim-le-addqi.c: New test. * gcc.target/vax/cmpelim-le-addsf.c: New test. * gcc.target/vax/cmpelim-le-addsi.c: New test. * gcc.target/vax/cmpelim-le-andhi.c: New test. * gcc.target/vax/cmpelim-le-andqi.c: New test. * gcc.target/vax/cmpelim-le-andsi.c: New test. * gcc.target/vax/cmpelim-le-ashlsi.c: New test. * gcc.target/vax/cmpelim-le-ashrsi.c: New test. * gcc.target/vax/cmpelim-le-divdf.c: New test. * gcc.target/vax/cmpelim-le-divhi.c: New test. * gcc.target/vax/cmpelim-le-divqi.c: New test. * gcc.target/vax/cmpelim-le-divsf.c: New test. * gcc.target/vax/cmpelim-le-divsi.c: New test. * gcc.target/vax/cmpelim-le-extendhisi.c: New test. * gcc.target/vax/cmpelim-le-extendqisi.c: New test. *
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 --- Comment #2 from CVS Commits --- The master branch has been updated by Maciej W. Rozycki : https://gcc.gnu.org/g:e552abe2ba27ccec0d7c0d050b4617f2f636dd63 commit r11-5796-ge552abe2ba27ccec0d7c0d050b4617f2f636dd63 Author: Maciej W. Rozycki Date: Sat Dec 5 18:26:27 2020 + PR target/95294: VAX: Convert backend to MODE_CC representation In the VAX ISA INSV bit-field insert instruction is the only computational operation that keeps the condition codes, held in the PSL or Processor Status Longword register, intact. The instruction is flexible enough it could potentially be used for data moves post-reload, but then reportedly it is not the best choice performance-wise, and then we have no addition operation available that would keep the condition codes unchanged. Futhermore, as usually with a complex CISC ISA, for many operations we have several machine instructions or instruction sequences to choose from that set condition codes in a different manner. Use the approach then where the condition codes only get introduced by reload, by definining instruction splitters for RTL insns that change condition codes in some way, by default considering them clobbered. Then to prevent code generated from regressing too much provide insns that include a `compare' operation setting the condition codes in parallel to the main operation. The manner condition codes are set by each insn is supposed to be provided by the whatever the SELECT_CC_MODE macro expands to. Given that individual patterns provided for the same RTL basic operation may set the condion codes differently keeping the information away from the insn patterns themselves would cause a maintenance nightmare and would be bound to fail in a horrible way sooner or later. Therefore instead let the patterns themselves choose which condition modes they support, by having one or more subst iterators applied and then have individual comparison operators require the specific condition mode each according to the codes used by the operation. While subst iterators only support one alternative each, there is actually no problem with applying multiple ones to a single insn with the result as intended, and if the corresponding subst attribute supplies an empty NO-SUBST-VALUE, then no mess results even. Make use of this observation. Add appropriate subst iterators to all the computational patterns then, according to the condition codes they usably set, including DImode ones and a substitute DImode comparison instruction in the absence of a CMPQ machine instruction, however do not provide a `cbranchdi4' named pattern as without a further development it regresses code quality by resorting to the `__cmpdi2' libcall where a simpler operation would do, e.g. to check for negativity the TSTL machine instruction may be executed over the upper longword only. This is good material for further work. Do not apply subst iterators to the increment- or decrement-and-branch patterns at this time; these may yet have to be reviewed, in particular whether `*jsobneq_minus_one' is still relevant in the context of the recent integer constant cost review. Also add a couple of peepholes to help eliminating comparisons in some problematic cases, such as with the BIT instruction which is bitwise-AND for condition codes only that has no direct counterpart for the actual calculation, because the BIC instruction which does do bitwise-AND and produces a result implements the operation with a bitwise negation of its input `mask' operand. Or the FFS instruction which sets the Z condition code according to its `field' input operand rather than the result produced. Or the bit-field comparisons we don't have generic middle-end support for. Code size stats are as follows, obtained from 17640 and 9086 executables built in `check-c' and `check-c++' GCC testing respectively: check-c check-c++ samples average median samples average median --- regressions 1813 0.578% 0.198% 289 0.349% 0.175% unchanged 15160 0.000% 0.000% 8662 0.000% 0.000% progressions 667 -0.589% -0.194% 135 -0.944% -0.191% total 17640 0.037% 0.000% 9086 -0.003% 0.000% Outliers: old new change %change filename 24062950+544+22.610 20111208-1.exe 43145329+1015 +23.528 pr39417.exe 22353055+820+36.689 990404-1.exe 26314213+1582 +60.129 pr57521.exe 30635579
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
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/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||m...@3am-software.com --- Comment #1 from Eric Gallager --- cc-ing vax maintainer listed in MAINTAINERS
