Re: gengtype state & srcdir???
2011/3/7 Basile Starynkevitch : > However, some source files considered by gengtype are outside of $(srcdir) > because they are somewhere else in the GCC source tree. > So most of the source files considered by gengtype are indeed in the > $(srcdir) of the gcc/Makefile.in that is in the gcc/ subdirectory of GCC > source tree. But some are outside, e.g. in include/ or libcpp/ > > > I feel we could improve that by passing the GCC source tree as the -S > argument to GCC, etc. > > Do you think it is worth working on that now? Could such a minor patch be > accepted for 4.6 (I believe that no, but I am not sure). This would be a fine patch but certainly not for 4.6. -- Laurynas
Re: Why IRA stores in frame, not in callee-saved reg?
Georg-Johann Lay schrieb:
> In current trunk (r170704), 4.4-branch and 4.5-branch I observe the
> following optimization issue in IRA: It saves regs in the frame
> instead of in callee-saved registers which would be much smarter.
>
> In the following C source, foo2 is compiled as desired (push/pop r17
> to save r24). In foo1 and foo3 r24 is saved in the frame. The old
> lreg/greg allocator of 4.3-branch generates fine code for all functions.
>
> Saving a reg in the frame should only be done if running out of hard
> registers because setting up frame(pointer) and accessing frame is
> very expensive on avr.
>
> Maybe someone can give me a hint what's going wrong.
>
> gcc configured
>
> /gnu/source/gcc.gnu.org/trunk/configure --target=avr --prefix=...
> --enable-languages=c,c++ --disable-libssp --disable-libada
> --disable-nls --disable-shared
>
> and sources compiled
>
> with -Os -mmcu=atmega8 -c -dp -da -fira-verbose=100
>
> /*/
> void bar0 (void);
> void bar1 (char);
>
> void foo1 (char x)
> {
> bar0();
> bar1(x);
> }
>
>
> char foo2 (char x)
> {
> bar1(x);
>
> return x;
> }
>
> char foo3 (char x)
> {
> bar0();
>
> return x;
> }
> /*/
>
> FYI, I attached IRA dumps and asm output
>
> As far I can see target avr gives appropriate costs for memory and
> register moves.
>
> IRA printout is as follows:
>
Returning memory move costs 4 times higher (8 instead of 2) for QI
memory moves, IRA/reload generates code as expected.
Is there any other way than lying about the costs?
IRA doues not take into account costs implied by generating new stack
slots and setting up frame pointer. AFAIK there is no hook to
influence that. How can a target describe costs generated by setting
up stack slots and accessing them?
Johann
Re: __builtin_clzll and uintmax_t
Quoting Jakub Jelinek :
On Sun, Mar 06, 2011 at 09:56:52AM +0100, Marc Glisse wrote:
>uintmax_t is the largest of the standard unsigned C types, so it
cannot be larger than unsigned long long.
That's a gcc property then. The C99 standard only guarantees that
uintmax_t is at least as large as unsigned long long, but it is
allowed to be some other larger type:
Yeah, it could be larger than unsigned long long.
On no target GCC supports currently it is larger than long long
though currently.
But it's not too far out that a future target might have that.
E.g. if the arc/mxp toolchain was revived, with the 128 bit word with
of the mxp, it would be natural to have a named integer type for 128bit.
Right now, the branch has 16 bit short, 16 or 32 bit int, 32 bit long,
64 bit long long, and an anonymous 128 bit type to handle words.
(The preferred size to compute addresses, loop counters and
vectorizable integers is 16 bit.)
Even if the GCC mxp port never gets integrated in mainline, I think
it is likely that in the future, we'll have a GPU port or CPU vector
extension support with an intmax_t type wider than long long.
It is also an ABI issue, you can't change what uintmax_t was
once you use some particular type in an ABI.
As long as you define the libc view of the kernel interface appropriately,
you should be able to multilib around this issue.
Bonus points if anyone implements a scheme so that only those object files
for which it matters need to exist in multiple versions.
I.e. if we don't have any function argument / return value, aggregate member,
or debug info involving intmax_t / unitmax_t, we should be able to use the
same object file with code of either intmax_t size.
At any rate, for embedded and/or new targets, ABI churn is often
more acceptable.
What you could do is use __builtin_clzll if sizeof (uintmax_t) ==
sizeof > (unsigned long long),
for sizeof (uintmax_t) == 2 * sizeof (unsigned long long) perhaps use
int
clzmax (uintmax_t x)
{
...
and give up for other cases.
The main point is to have the code fail to compile if the size is not
supported, and implement this abstraction in one place, so handling of
new sizes can be added in an efficient manner.
In fact, without the ability to test the 2*long long code, I would
prefer the code to be written so that the compiler will complain initially
when this code is used, so people have to explicitly enable it to be used,
and are thus aware of what might not quite work.
Re: Why IRA stores in frame, not in callee-saved reg?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/11 04:36, Georg-Johann Lay wrote: > > IRA doues not take into account costs implied by generating new stack > slots and setting up frame pointer. AFAIK there is no hook to > influence that. How can a target describe costs generated by setting > up stack slots and accessing them? IRA isn't particularly good about accounting for prologue/epilogue costs, both the saves/restores and FP setup. Part of the problem is the cost is really amortized across potentially many allocnos which potentially use the callee-saved registers. Unfortunately, there's no way to know that apriori. It's an issue Vlad and I have discussed, but we haven't come to any kind of conclusions for how to better model the costs of the prologue/epilogue vs the savings of allocing more allocnos to callee-saved hard regs vs caller-saved hard regs or memory. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNdlNBAAoJEBRtltQi2kC7ShUIAJV2DgMhDV+t4rltCnnK6mDS SKvAWBw9fYyenDmSHYyYR0ABZbltRe98Q2B1XsQw7Ah5e2zXD11Xmr5EzZ+W0+uE LPLWphMDSnaQpy20qwnDhlOpgH3hChZ/4KwhtL3HHgzTq6dFw+v8k2UI2CBaMe2N eTLy3YP4AbbYyvBPbwMUnyxurmbt4nz98lvCi6L+bqBV0iWMXTOY8hce3+aPj1ib 1a70eTEP8CD+PKCpq+xPkl3yVCcwKsOCyHhFxFHscBZGLtbOLhmBpdwED0eW0Jbe dUxIYJyxFAZp4djm6+RFosPDIVJe2fBt/jW/ZzhV3h1zlcMxZNt2qxWsQi+2Y7E= =Pjsd -END PGP SIGNATURE-
Re: debug & trace printing from GCC plugins (& MELT extensions)
On 07/03/2011 15:39, Basile Starynkevitch wrote: > So please accept (at least temporily) the usefulness of debug & trace > printing. > > My question then is how to implement it nicely? > And I don't know if debug printing should go to stdout or to stderr. MELT is for writing new passes, right? So it could use the existing per-pass dump files mechanism I would expect. cheers, DaveK
Re: Why IRA stores in frame, not in callee-saved reg?
On 03/08/2011 06:36 AM, Georg-Johann Lay wrote:
Georg-Johann Lay schrieb:
In current trunk (r170704), 4.4-branch and 4.5-branch I observe the
following optimization issue in IRA: It saves regs in the frame
instead of in callee-saved registers which would be much smarter.
In the following C source, foo2 is compiled as desired (push/pop r17
to save r24). In foo1 and foo3 r24 is saved in the frame. The old
lreg/greg allocator of 4.3-branch generates fine code for all functions.
Saving a reg in the frame should only be done if running out of hard
registers because setting up frame(pointer) and accessing frame is
very expensive on avr.
Maybe someone can give me a hint what's going wrong.
gcc configured
/gnu/source/gcc.gnu.org/trunk/configure --target=avr --prefix=...
--enable-languages=c,c++ --disable-libssp --disable-libada
--disable-nls --disable-shared
and sources compiled
with -Os -mmcu=atmega8 -c -dp -da -fira-verbose=100
/*/
void bar0 (void);
void bar1 (char);
void foo1 (char x)
{
bar0();
bar1(x);
}
char foo2 (char x)
{
bar1(x);
return x;
}
char foo3 (char x)
{
bar0();
return x;
}
/*/
FYI, I attached IRA dumps and asm output
As far I can see target avr gives appropriate costs for memory and
register moves.
IRA printout is as follows:
Returning memory move costs 4 times higher (8 instead of 2) for QI
memory moves, IRA/reload generates code as expected.
Is there any other way than lying about the costs?
IRA doues not take into account costs implied by generating new stack
slots and setting up frame pointer. AFAIK there is no hook to
influence that. How can a target describe costs generated by setting
up stack slots and accessing them?
First of all, defining equal costs for moving into memory and into
register (2 in both cases) is wrong way to direct IRA.
In case of test1, pseudo 42 is in two insns involving hard register 24.
Therefore its cost is decreased in ira-costs.c. After that it is
increased on the same value because the pseudo intersects one call and
the cost of ld/st (for save/restore) is the same as for moving its value
into a general register. Because r24 is the first in the hard register
allocation order, IRA chooses r24.
So making ld/st a bit more costly than hard register moving would solve
the problem. Unfortunately, it does not happens because the two move
insns involving p42 and hard register 24 are taken into account twice
(once in ira-costs.c and another one ira-conflicts.c:process_regs_for copy).
The following patch would solve the problem. I'll submit it when gcc is
in stage 1. The patch looks harmless but changes in ira-costs.c
frequently trigger reload failures. Therefore the patch needs thorough
testing and stage1 is best time to do it.
Thanks for pointing the problem. It helped to find some cost
calculation pitfall which was probably introduced by an IRA change in
ira-costs.c inconsistent with the code in ira-conflicts.c.
Index: ira-conflicts.c
===
--- ira-conflicts.c(revision 170786)
+++ ira-conflicts.c(working copy)
@@ -432,8 +432,7 @@ process_regs_for_copy (rtx reg1, rtx reg
rclass = REGNO_REG_CLASS (allocno_preferenced_hard_regno);
mode = ALLOCNO_MODE (a);
cover_class = ALLOCNO_COVER_CLASS (a);
- if (only_regs_p && insn != NULL_RTX
- && reg_class_size[rclass] <= (unsigned) CLASS_MAX_NREGS (rclass, mode))
+ if (only_regs_p && insn != NULL_RTX)
/* It is already taken into account in ira-costs.c. */
return false;
index =
ira_class_hard_reg_index[cover_class][allocno_preferenced_hard_regno];
gcc-4.4-20110308 is now available
Snapshot gcc-4.4-20110308 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110308/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 170794 You'll find: gcc-4.4-20110308.tar.bz2 Complete GCC (includes all of below) MD5=8c17024142479a8cafae9670367798b7 SHA1=b97761b139b979f157bd103c32d68b123bae0f16 gcc-core-4.4-20110308.tar.bz2C front end and core compiler MD5=39fa3ef480be0f5a413254fd3c5046e1 SHA1=2ae447a1e80d0fcbbc62de929668e873f098cda8 gcc-ada-4.4-20110308.tar.bz2 Ada front end and runtime MD5=1faa47c05710c42b283c475aedcbd7dc SHA1=f344f5024d3fb1644a0acfd670cdf3d28f857c44 gcc-fortran-4.4-20110308.tar.bz2 Fortran front end and runtime MD5=a7ee45770dd5c7730a968f16c7f2d1eb SHA1=0293b509a3a7a7c0cea12cb84087314611fdf545 gcc-g++-4.4-20110308.tar.bz2 C++ front end and runtime MD5=7520d1f48571cc359fa96cfd73a5dfe9 SHA1=60da039bf2c7761c62f9b4a23efa96ab5132fba5 gcc-go-4.4-20110308.tar.bz2 Go front end and runtime MD5=2335179e27934089de2e847c9037e0b5 SHA1=169af55003faff81beb71cad625b1096d4d0ffda gcc-java-4.4-20110308.tar.bz2Java front end and runtime MD5=ff691877d6bc4f576ca79dcef97b733b SHA1=f8c6acd0dc5e6254c1e1ca1725a3af49100b21b4 gcc-objc-4.4-20110308.tar.bz2Objective-C front end and runtime MD5=ef4f8d39c829d9d49be967ea26ba3868 SHA1=d26c958b57e8b1651381a717beb87c67cca08d2c gcc-testsuite-4.4-20110308.tar.bz2 The GCC testsuite MD5=b17a6cd9c94039ad08e3cac1e7ef452f SHA1=ec2a101d6c76fdc24a66d40edf8be94269963bb4 Diffs from 4.4-20110301 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
gcc4.1.2 and 4.3.2 has different default behavior
Hello All,
I have encountered one issue when write a simple test code.
#inlcude
int main{
const char* str = "";
std::cout<<"str len: "<
Re: debug & trace printing from GCC plugins (& MELT extensions)
On Tue, 08 Mar 2011 21:07:39 +
Dave Korn wrote:
> On 07/03/2011 15:39, Basile Starynkevitch wrote:
>
> > So please accept (at least temporily) the usefulness of debug & trace
> > printing.
> >
> > My question then is how to implement it nicely?
>
> > And I don't know if debug printing should go to stdout or to stderr.
>
> MELT is for writing new passes, right? So it could use the existing
> per-pass dump files mechanism I would expect.
Yes, but some processing happens outside passes (like complex
initializations at least). And I believe this is also true for some
other plugins. The question becoms where and how should the debug
printing happens in that case.
I'm sure the question is not MELT specific. Imagine a plugin (coded in
C) which uses some database, or some web services, or provide a web or
a graphical interface. Then its initialization code also need debug
printing.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: gcc4.1.2 and 4.3.2 has different default behavior
Yixuan Huang writes:
> I have encountered one issue when write a simple test code.
> #inlcude
> int main{
> const char* str = "";
> std::cout<<"str len: "< return 0;
> }
>
> If I compile on gcc version 4.1.2 20070115 (SUSE Linux), it can be
> compiled successfully. Otherwise, on gcc version 4.3.2 [gcc-4_3-branch
> revision 141291] (SUSE Linux), it will show
> linux-lht2:/home/yixuan # g++ aa.cpp
> aa.cpp: In function ‘int main()’:
> aa.cpp:6: error: ‘strlen’ was not declared in this scope
>
> I don't know where can I get the information to explain the different
> behavior?
This message is not appropriate for the mailing list gcc@gcc.gnu.org.
It would be appropriate for gcc-h...@gcc.gnu.org. Please take any
followups to gcc-help. Thanks.
gcc 4.3 is more careful about having one C++ header file include
another. The function strlen is defined in . In gcc 4.1
#include'd . In gcc 4.3 it does not.
This is briefly mentioned at http://gcc.gnu.org/gcc-4.3/changes.html:
"Header dependencies have been streamlined, reducing unnecessary
includes and pre-processed bloat."
Ian
