[Bug target/112298] Poor code for DImode operations on H8 port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112298 Roger Sayle changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|

[Bug target/112298] Poor code for DImode operations on H8 port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112298 Jeffrey A. Law changed: What|Removed |Added Target||h8300 Priority|P3

[Bug target/112298] New: Poor code for DImode operations on H8 port

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112298 Bug ID: 112298 Summary: Poor code for DImode operations on H8 port Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

Re: [PATCH][ARM] Cleanup logical DImode operations

Hi Christophe, > After this was committed (r274823), I've noticed 2 regressions on arm*: > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20 > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18 > > Does this test still pass for you? You're right,

Re: [PATCH][ARM] Cleanup logical DImode operations

On Thu, 22 Aug 2019 at 14:03, Kyrill Tkachov wrote: > > Hi Wilco, > > On 7/19/19 12:30 PM, Wilco Dijkstra wrote: > > > > Cleanup the logical DImode operations since the current implementation > > is way > > too complicated. Thumb-1, Thumb-2, VFP/Neon

Re: [PATCH][ARM] Cleanup logical DImode operations

Hi Wilco, On 7/19/19 12:30 PM, Wilco Dijkstra wrote: Cleanup the logical DImode operations since the current implementation is way too complicated.  Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work differently, resulting in a bewildering number of expansions, patterns and splits across

Re: [PATCH][ARM] Cleanup logical DImode operations

  ping       Cleanup the logical DImode operations since the current implementation is way  too complicated.  Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work differently,  resulting in a bewildering number of expansions, patterns and splits across  several md files.  All

Re: [PATCH][ARM] Cleanup logical DImode operations

ping   Cleanup the logical DImode operations since the current implementation is way too complicated.  Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work differently, resulting in a bewildering number of expansions, patterns and splits across several md files.  All this complexity

[PATCH][ARM] Cleanup logical DImode operations

Cleanup the logical DImode operations since the current implementation is way too complicated. Thumb-1, Thumb-2, VFP/Neon and iwMMXt all work differently, resulting in a bewildering number of expansions, patterns and splits across several md files. All this complexity is counterproductive

Re: DImode operations

Hi, Thanks for your guys advice. Now the gcc is built succeed first time(without headers). Now I have to keep going for newlib. Thanks very much.

Re: DImode operations

daniel tian daniel.xnt...@gmail.com writes: when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg. Here is the info: ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3': ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable

Re: DImode operations

HｉDave: I add the DI, SF, DFpattern. But when build the libgcc2.c, it still cause errors. 　　The error information： ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__muldi3': ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:557: internal compiler error: in emit_move_insn, at

Re: DImode operations

Sorry, Dove, I just gotta the solution to debug the cc1. Dove told me the link, and I just missed. Now I checked. So sorry, I ask the stupid question again. But the former question, I am still puzzled. Thanks.

Re: DImode operations

Yeah. You are right. I debuged the cc1 file with insight. It caused by FUNCTION_VALUE macro which means the error happened in function return. Because my target always return a SImode. I fixed it. To debug the cc1 is always a good point to hack the bug. But there are still other error exist. I

Re: DImode operations

Hi Dave: when I build the libgcc2.c, an unrecognizable RTL exist. Its about subreg. Here is the info: ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function '__mulvsi3': ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c:169: error: unrecognizable insn: (insn 24 26 25 3

Re: DImode operations

Thanks. I am working for it now. But I have a question about how to debug the cc1 with libgcc1.c. because if I run the cc1 to build the libgcc2.c, lots of errors occurred. Run the cc1 with the command: ./cc1 -g -I../../rice-gcc-4.3.0/gcc -I../../rice-gcc-4.3.0/gcc/../include

Re: DImode operations

Another problem I found when hacking other port. Do I need to write SF, DF move operations? And basic arithmetic insn patterns like ADD, SUB in DImode? Because in CRX port (as I knew, there is no float point unit in this cpu), DI,SF,DF mode have 'move' operation. and there are subtract, add

Re: DImode operations

daniel tian wrote: Thanks. I am working for it now. But I have a question about how to debug the cc1 with libgcc1.c. because if I run the cc1 to build the libgcc2.c, lots of errors occurred. Run the cc1 with the command: ./cc1 -g -I../../rice-gcc-4.3.0/gcc

Re: DImode operations

daniel tian wrote: Another problem I found when hacking other port. Do I need to write SF, DF move operations? And basic arithmetic insn patterns like ADD, SUB in DImode? Because in CRX port (as I knew, there is no float point unit in this cpu), DI,SF,DF mode have 'move' operation. and

DImode operations

Hi: Do I have to write the DImode operations on my *.md target description file? Now I build my gcc first, there is an error on libgcc2.c. which is an __muldi3 function. The error information is: ../../../rice-gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __muldi3: ../../../rice-gcc

Re: DImode operations

daniel tian wrote: Hi: Do I have to write the DImode operations on my *.md target description file? Yes. movMM must be implemented for all types that you want the compiler to be able to handle at all; it's the only way it knows to move them around. (Technically, it's supposed