From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Haggard To: egcs@cygnus.com Subject: Re: A prototype patch for tree.h/tree.def/calls.c Date: Tue, 19 Aug 1997 21:22:30 -0000 Message-id: <33FA0E96.630@shellus.com> In-reply-to: A prototype patch for tree.h/tree.def/calls.c X-SW-Source: 1997-08/0195.html Jeffrey A Law wrote: > > In message you write: > > > But regardless of what other parts of gcc are doing, using "unsigned" > > > in the prototype for xmalloc is wrong and such a change will not be > > > installed. > > > > It makes nosenses when the definion of xmalloc uses unsigned > > and its prototype uses size_t. It is much worse. > Providing a prototype that is blatently wrong will not be accepted. > There's no use argueing about this, an incorrect patch will not > be accepted. Actually, you are both sort-of right on this. In some programs, the definition of xmalloc takes a signed or unsigned int, and in some it takes a size_t. The mips-tfile.c is the worst offender: Its definition of xmalloc starts like: > > PTR_T > xmalloc (size) > Size_t size; > { Earlier in mips-tfile.c, "Size_t" is defined as: > #if defined(__OSF1__) || defined(__OSF__) || defined(__osf__) > #define Size_t long unsigned int > #else > #define Size_t unsigned int > #endif Both cccp.c and protoize.c contain definitions of xmalloc with a size_t argument. And just for completeness, bi-arity.c, bi-lexer.c, bi-opcode.c, and bi-opname.c also have the trivial inconsistency that they contain definitions of xmalloc that expect an int, not an unsigned int. All other definitions of xmalloc do, however, take unsigned int. -- Ian Haggard || ian@shellus.com (work) || IanHaggard@juno.com (home) GNU/Linux -- "Oh, no, Mr Bill!" || #define employer_opinion !my_opinion From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey A Law To: egcs@cygnus.com Subject: PA port & haifa Date: Tue, 19 Aug 1997 22:15:40 -0000 Message-ID: <33FA0E96.630@shellus.com> X-SW-Source: 1997-08/0196.html Message-ID: <19970819221540.RumNpmOvW7UZHOOE-z0I_zlUezIObsuljEpwCvsBgUg@z> In the next snapshot, the PA port will default to using the haifa scheduler. After some tuning of the PA backend, haifa is showing a noticable improvement in FP intensive code. While there are still some cases where the generated code is slower, the majority of the time the code is significantly faster. For specfp92 I'm seeing an overall improvement of about 6.5%. I encourage others to test with haifa and tune the scheduling parameters to get good performance from haifa. As haifa improves in both code reliability and speed, we can make it the default for additional cpus -- with the goal of having the haifa scheduler replace the old scheduler. Jeff