Merging identical functions in GCC
Hello! There is very good blog post about the problem: http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html A couple of days ago I've learned that the Microsoft linker can merge functions with binary identical bodies. Looks rather good idea, > especially with templates, and it seems that gcc does not implement this. Will GCC support this feature? It might be very useful in some cases, reduce code size and locality. Some info about possible problems can be found here: http://blogs.msdn.com/oldnewthing/archive/2005/03/22/400373.aspx So, due to incompatibilities with debugging and C/C++ standards this feature should be optional and disabled by default. Best regards, Michael
Re: STL slist/map containers concurrent/thread-safe access
Hi Kalaky, #1. Please do not cross post to GCC-help and GCC lists. #2. GCC@gcc.gnu.org is not an appropriate forum for your question. #3. [EMAIL PROTECTED] is not an appropriate forum for your question. #4. Your question is a general C++ question, not a GCC question. > Given that removing/inserting elements from a map/slist/whatever does > not invalidate iterators to list elements, it is safe to use the > element that the iterator "points" to ? The rules for iterator invalidation are tightly dependent on the container involved. I recommend reading the ISO 14882 standard very carefully about what STL containers guarantee about their iterators. (I always have to look them up myself -- I tend to pessimistically over-assume that my iterators are invalidated more often then they really are in actuality.) I'm pretty sure that removing an element from a container will cause any iterator pointing to that element to become invalidated, for all containers. How do you have an iterator to an element in a container, when that element hasn't been inserted into the container yet? *AFTER* an element is inserted into a container, and then you acquire an iterator to that element, I presume that iterator properly refers to that element. I recommend you use a "Safe STL" for your development. It will help you discover problematic STL usage in your code. Here are some "safe STL" implementations: http://www.horstmann.com/safestl.html http://www.stlport.org/ http://gcc.gnu.org/onlinedocs/libstdc++/debug.html Good luck! --Eljay
Re: Merging identical functions in GCC
Hi, Isn't this what you describe here the same as COMDAT? Gr. Steven On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote: Hello! There is very good blog post about the problem: http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html > A couple of days ago I've learned that the Microsoft linker can merge > functions with binary identical bodies. Looks rather good idea, > especially with templates, and it seems that gcc does not implement this. Will GCC support this feature? It might be very useful in some cases, reduce code size and locality. Some info about possible problems can be found here: http://blogs.msdn.com/oldnewthing/archive/2005/03/22/400373.aspx So, due to incompatibilities with debugging and C/C++ standards this feature should be optional and disabled by default. Best regards, Michael
newbie : modifying C++ grammar
I have downloaded and built gcc-core and gcc-g++ (both 4.1.1). I am not able to locate the yacc file for C++. I want to experiment with some grammar changes. -Suresh __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/
Re: Merging identical functions in GCC
Steven Bosscher wrote: Isn't this what you describe here the same as COMDAT? Well, MS VC have an option "enable COMDAT folding" - which turns ON merging of identical functions. BTW, this is linker option... should it be addressed to GCC's LTO? I'm not sure if function body is equivalent to "COMDAT".
Building a Cross compiler for Cold Fire
Hi all, i am trying to build a GCC Cross-compiler for Cold Fire on cygwin. The Source versions i am using are binutils 2.17 gcc 4.1.1 newlib 1.14 The way in which i am building the tool chain - build/install binutils: cd /binutil-2.17 ./configure --target=m68k-elf --prefix=/usr make make install - build/install compiler cd gcc-4.1.1 ./configure --target=m68k-elf --prefix=/usr make LANGUAGE="C" the native compiler i am using is gcc 3.4.4 Cygwin-special my binutils built successfully. while building the compiler i am getting error while running make "compiler cannot generate output file" Can any one tell me what are the stable sources for building a GCC Cross compiler for Coldfire or are there any other steps to follow while installation. Is there any way out of it? Regards, Rohit
Re: newbie : modifying C++ grammar
Suresh Shukla wrote: I have downloaded and built gcc-core and gcc-g++ (both 4.1.1). I am not able to locate the yacc file for C++. I want to experiment with some grammar changes. All parsers in GCC, but the Java parser, are hand written. The C++ parser is in gcc/cp/parser.c and was rewritten for 3.4. It is a backtracking recursive-descent parser (Fortran is one too; C does not need backtracking). Though there are examples of C++ grammars written using Yacc, C++ and Fortran are so complex (and C comes close when you add OpenMP for example) that using Yacc only adds complexity. Paolo
20020103-1.c XPASS on Darwin
Geoff, Are we now passing gcc.dg/20020103-1.c on Darwin due to the newer cctools in Xcode 2.4? I ask because I'm going to prepare patches tonight to eliminate some of the XPASS results in the libstdc++ testsuite tonight and post them to gcc-patches. If the newer Xcode is the origin of the new gcc XPASS, we might as fix that one as well. My reasoning is that since gcc trunk now requires Xcode 2.4's cctools to build which in turn requires MacOS X 10.4 so we can assume the latest 10.4.x release and at least Xcode 2.4 when deciding what is really an XPASS or not. Jack
How to pass option to arch-linux-elf-run in dejagnu
Hi, I'm trying to test our Compiler (ported from gcc-3.4.2) using the gcc test suite. According to some reasons, I need to pass some options to arch-linux-elf-run in the dejagnu frame work. Is there anyone can give me a hint about his? Thanks in advance, Aladdin
Re: Merging identical functions in GCC
"Steven Bosscher" <[EMAIL PROTECTED]> writes: > Isn't this what you describe here the same as COMDAT? Not exactly. COMDAT means that the compiler can generate multiple instances of, say, the list functions, and only one version will be included in the final executable. However, if you use both list and list, they will both wind up in the executable. The proposal here is that in the case where list and list generate identical code, only one version winds up in the executable, with two symbols associated with it. I think Danny has a 75% implementation based on hashing the RTL for a section and using that to select the COMDAT section signature. Or the hashing can be done in the linker, but it still needs compiler help to know when it is permissible. Ian > On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote: > > Hello! > > > > There is very good blog post about the problem: > > http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html > > > A couple of days ago I've learned that the Microsoft linker can merge > > > functions with binary identical bodies. Looks rather good idea, > > > especially with templates, and it seems that gcc does not implement this. > > > > Will GCC support this feature? > > It might be very useful in some cases, reduce code size and locality. > > > > > > Some info about possible problems can be found here: > > http://blogs.msdn.com/oldnewthing/archive/2005/03/22/400373.aspx > > > > So, due to incompatibilities with debugging and C/C++ standards > > this feature should be optional and disabled by default. > > > > > > Best regards, > > Michael > >
Bootstrap failure on SuSE 10.1
I must be doing something extraordinarily stupid, but I can't figure out what it is: I can't bootstrap anymore since subversion revisions from early January this year on a system as widely available as stock SuSE10.1. Here's what's happening: starting with revision 109241 --- config: 2006-01-02 Paolo Bonzini <[EMAIL PROTECTED]> PR target/25259 * stdint.m4: New. gcc: 2006-01-02 Paolo Bonzini <[EMAIL PROTECTED]> PR target/25259 * Makefile.in (DECNUMINC): Include libdecnumber's build directory. [...] I get bootstrap failures like this: gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../svn-mainline/gcc -I../../svn-mainline/gcc/. -I../../svn-mainline/gcc/../include -I../../svn-mainline/gcc/../libcpp/include -I../../svn-mainline/gcc/../libdecnumber -I../libdecnumber ../../svn-mainline/gcc/c-lang.c -o c-lang.o In file included from ../../svn-mainline/gcc/input.h:25, from ../../svn-mainline/gcc/tree.h:26, from ../../svn-mainline/gcc/c-lang.c:27: ../../svn-mainline/gcc/../libcpp/include/line-map.h:56: error: 'CHAR_BIT' undeclared here (not in a function) I can prevent the failure if I remove the -I../libdecnumber from the command line. The reason is that c-lang.c contains #include "config.h" at the beginning, and for some reason the preprocessor decides to pick up the config.h from ../libdecnumber instead of from ./ . If I run above commandline with -E instead of -c, here is the top of the preprocessor output with -I../libdecnumber: # 1 "../../svn-mainline/gcc/c-lang.c" # 1 "" # 1 "" # 1 "../../svn-mainline/gcc/c-lang.c" # 23 "../../svn-mainline/gcc/c-lang.c" # 1 "../libdecnumber/config.h" 1 # 24 "../../svn-mainline/gcc/c-lang.c" 2 On the other hand, when I omit -I../libdecnumber, I get the output that was probably expected: # 1 "../../svn-mainline/gcc/c-lang.c" # 1 "" # 1 "" # 1 "../../svn-mainline/gcc/c-lang.c" # 23 "../../svn-mainline/gcc/c-lang.c" # 1 "./config.h" 1 3 # 1 "./auto-host.h" 1 3 This must be something that someone has seen before and knows how to deal with. Any ideas? Best Wolfgang PS: Just in case, this is how I build: ../svn-mainline/configure --prefix=/home/bangerth/bin/gcc-4.2-pre --enable-languages=c,c++ && make bootstrap - Wolfgang Bangerthemail:[EMAIL PROTECTED] www: http://www.math.tamu.edu/~bangerth/
Re: Merging identical functions in GCC
On 15 Sep 2006 09:27:32 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Steven Bosscher" <[EMAIL PROTECTED]> writes: > Isn't this what you describe here the same as COMDAT? Not exactly. COMDAT means that the compiler can generate multiple instances of, say, the list functions, and only one version will be included in the final executable. However, if you use both list and list, they will both wind up in the executable. The proposal here is that in the case where list and list generate identical code, only one version winds up in the executable, with two symbols associated with it. I think Danny has a 75% implementation based on hashing the RTL for a section and using that to select the COMDAT section signature. Or the hashing can be done in the linker, but it still needs compiler help to know when it is permissible. Yup, that's what i've got. It works when they generate value wise identical code (effectively it allows as different of code your value numbering can determine is the same). There are of course, collisions possible in the hash, and in the absolute worst case, it is possible to end up with no warning but wrong results. In particular, if you get a collision and the length of the functions happens to be the same, i don't believe the linker will complain about the symbol size changing.
Re: Building a Cross compiler for Cold Fire
Rohit Arul Raj wrote: Hi all, i am trying to build a GCC Cross-compiler for Cold Fire on cygwin. The Source versions i am using are binutils 2.17 gcc 4.1.1 newlib 1.14 The way in which i am building the tool chain - build/install binutils: cd /binutil-2.17 ./configure --target=m68k-elf --prefix=/usr make make install The general wisdom is to build in a different directory from the source distribution (for both binutils and gcc): mkdir bin-build cd bin-build ../binutils-2.17/configure --target=m68k-elf --prefix=/usr make make install - build/install compiler cd gcc-4.1.1 ./configure --target=m68k-elf --prefix=/usr make LANGUAGE="C" You probably also want --with-newlib. Copy newlib-1.14/newlib into the gcc source directory. The gcc build will pick up the correct include files and build newlib. Also --disable-libssp, because of a GCC bug. the native compiler i am using is gcc 3.4.4 Cygwin-special my binutils built successfully. while building the compiler i am getting error while running make "compiler cannot generate output file" This message is not about your host compiler. It is generated when the build attempts to compile a program using the cross compiler. Look in config.log in the directory in which the compile is run for information about the failure. Often, when I get this kind of error, I will cd to the build directory, set the PATH to include the binutils install directory if necessary, and run the failing command. I can then use -E or --print-search-paths or whatever to figure out why the compiler cannot create an executable. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: Merging identical functions in GCC
On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote: > I think Danny has a 75% implementation based on hashing the RTL for a > section and using that to select the COMDAT section signature. Or the > hashing can be done in the linker, but it still needs compiler help to > know when it is permissible. For code sections (I assume read-only), isn't the linker always able to merge identical ones? What can the compiler do better than the linker? Just curious, Laurent
Re: Merging identical functions in GCC
Daniel Berlin wrote: There are of course, collisions possible in the hash, and in the absolute worst case, it is possible to end up with no warning but wrong results. In particular, if you get a collision and the length of the functions happens to be the same, i don't believe the linker will complain about the symbol size changing. In case of hash collision, can't we just compare function body, byte by byte? Shouldn't be a big performance hit I think.
Re: Merging identical functions in GCC
On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: > There are of course, collisions possible in the hash, and in the > absolute worst case, it is possible to end up with no warning but > wrong results. In particular, if you get a collision and the length > of the functions happens to be the same, i don't believe the linker > will complain about the symbol size changing. In case of hash collision, can't we just compare function body, byte by byte? Shouldn't be a big performance hit I think. This is the part where Ian said "without help from the linker". The linker has no reason to do this unless we tell it, and the compiler doesn't see the other function body at the time of generating the hash (since it could be in another .o file).
Re: Merging identical functions in GCC
On 9/15/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote: On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote: > I think Danny has a 75% implementation based on hashing the RTL for a > section and using that to select the COMDAT section signature. Or the > hashing can be done in the linker, but it still needs compiler help to > know when it is permissible. For code sections (I assume read-only), isn't the linker always able to merge identical ones? What can the compiler do better than the linker? The linker doesn't know what the code does. The compiler does. Therefore, the compiler always can do a better job, as it can correctly identify more things as doing the same thing. --Dan
Re: Merging identical functions in GCC
On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote: > >> I think Danny has a 75% implementation based on hashing the RTL for a > >> section and using that to select the COMDAT section signature. Or the > >> hashing can be done in the linker, but it still needs compiler help to > >> know when it is permissible. On 9/15/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > >For code sections (I assume read-only), isn't the linker always able to > >merge identical ones? What can the compiler do better than the linker? On Fri, Sep 15, 2006 at 02:46:12PM -0400, Daniel Berlin wrote: > The linker doesn't know what the code does. The compiler does. > Therefore, the compiler always can do a better job, as it can > correctly identify more things as doing the same thing. It seems to me that most candidates for merging that could be eliminated by this approach are of the form std::container::some_method(...) where PodT is a POD type. But it might be better to refactor the library so that all container functions that, for PODs, depend only on the size of the objects in question, use common code.
Re: Merging identical functions in GCC
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> > I think Danny has a 75% implementation based on hashing the RTL for a
> > section and using that to select the COMDAT section signature. Or the
> > hashing can be done in the linker, but it still needs compiler help to
> > know when it is permissible.
>
> For code sections (I assume read-only), isn't the linker always able to
> merge identical ones? What can the compiler do better than the linker?
The linker can't merge just any identical code section, it can only
merge code sections where that is permitted. For example, consider:
int foo() { return 0; }
int bar() { return 0; }
int quux(int (*pfn)()) { return pfn == &foo; }
Compile with -ffunction-sections. If the linker merges sections, that
program will break.
I think that in general it would be safe to merge any equivalent
COMDAT code section, though.
Ian
Re: Merging identical functions in GCC
It seems to me that most candidates for merging that could be eliminated by this approach are of the form std::container::some_method(...) Actually, even for non-POD types, it catches a lot of templatized member functions that mainly depend on size (but they are still container classes).
Re: Merging identical functions in GCC
On 15 Sep 2006 13:54:00 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> > I think Danny has a 75% implementation based on hashing the RTL for a
> > section and using that to select the COMDAT section signature. Or the
> > hashing can be done in the linker, but it still needs compiler help to
> > know when it is permissible.
>
> For code sections (I assume read-only), isn't the linker always able to
> merge identical ones? What can the compiler do better than the linker?
The linker can't merge just any identical code section, it can only
merge code sections where that is permitted. For example, consider:
int foo() { return 0; }
int bar() { return 0; }
int quux(int (*pfn)()) { return pfn == &foo; }
Compile with -ffunction-sections. If the linker merges sections, that
program will break.
I think that in general it would be safe to merge any equivalent
COMDAT code section, though.
Just like most other compiler optimizations,
as-if rule would apply here as well.
If the linker can fake the above or prevent the optimization to happen
only for above cases, the optimization can be safe
(e.g. if there's no relocation against the function other than direct call
and the function symbol is "hidden" (as in linker scoping),
the linker can know that the address of a function is not taken).
However, I'd like to note that the debug information could become screwy
under this optimization (as usual with any optimization of this sort)
and could potentially make debugger's life somewhat miserable
(e.g. a template of a pointers may end up having exactly the same code
thus eligible for merging by linker,
then debugger may not be able to tell what is the real type of the pointer,
and you'll get "impossible" stack traces, etc).
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
Re: Merging identical functions in GCC
Ian Lance Taylor wrote:
>I think Danny has a 75% implementation based on hashing the RTL for a
>section and using that to select the COMDAT section signature.
I don't think this is a good idea. With different compiler options the
same RTL can generate different assembly instructions. Consider the case
of compiling the same function multiple times with different names and
different CPU architectures selected. You'd actually want the linker
to merge the functions that ended up having the same assembly, but not
the ones with the same RTL but different assembly.
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Consider:
#include
template T foo(T a) { return a; }
template T bar(T a) { return a; }
int
main() {
assert((int (*)(int)) foo != (int (*)(int)) bar);
}
Both foo and bar get put in their own COMDAT section and their
RTL and assembly are the same, but it's not safe to merge them.
Simply merging identical COMDAT sections would have to be optional and
disabled by default as Michael Popov said at the start of this thread.
The only way I can see to do it safely would be to emit some sort
instruction not to merge a function when the compiler sees that its
address is taken.
Ross Ridge
Re: Merging identical functions in GCC
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
> Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > For code sections (I assume read-only), isn't the linker always able to
> > merge identical ones? What can the compiler do better than the linker?
>
> The linker can't merge just any identical code section, it can only
> merge code sections where that is permitted. For example, consider:
>
> int foo() { return 0; }
> int bar() { return 0; }
> int quux(int (*pfn)()) { return pfn == &foo; }
>
> Compile with -ffunction-sections. If the linker merges sections, that
> program will break.
Indeed.
The compiler could merge (or mark for linker) static functions whose
address is not taken, those are safe against this use.
But by your argument, I don't see when the compiler can merge excepted
in the case I just mentionned, at least for C? (I don't know C++ enough
to understand other messages in this thread :).
On the Ada side, there are a few tricks, in particular a program naively
similar to the C program above is not portable in its use of equality:
<<
4.5.2 Relational Operators and Membership Tests
[...]
13Two access-to-subprogram values are equal if they are the result of the
same evaluation of an Access attribute_reference, or if both are equal to the
null value of the access type. Two access-to-subprogram values are unequal if
they designate different subprograms. {unspecified [partial]} [It is
unspecified whether two access values that designate the same subprogram but
are the result of distinct evaluations of Access attribute_references are
equal or unequal.]
13.a Reason: This allows each Access attribute_reference for a subprogram
to designate a distinct "wrapper" subprogram if necessary to support
an indirect call.
>>
Now, it's not 100% clear whether subprogram that are never different in
their outcome are "different" as meant here. Generics instanciation (aka
template) can lead to the same access value for different types in
many implementation, I haven't seen a special case for those in the RM.
If you're using subprogram access as an enum type indeed your're loosing
a valuable code size optimization, may be a compile flag could be
useful.
Laurent
Re: Merging identical functions in GCC
Laurent GUERBY wrote:
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:
For code sections (I assume read-only), isn't the linker always able to
merge identical ones? What can the compiler do better than the linker?
The linker can't merge just any identical code section, it can only
merge code sections where that is permitted. For example, consider:
int foo() { return 0; }
int bar() { return 0; }
int quux(int (*pfn)()) { return pfn == &foo; }
Compile with -ffunction-sections. If the linker merges sections, that
program will break.
Indeed.
The compiler could merge (or mark for linker) static functions whose
address is not taken, those are safe against this use.
I wrote an tech report for a company where I used to work about this
optimization about 10 years ago, in the context of C++ templates.
(Unfortunately, it was internal-only, so I don't have a copy. Or,
perhaps fortunately; I don't remember if I said stupid things...)
Anyhow, I think that a combination of compiler/linker help and
programmer help are useful. There are some cases where you can do this
automatically, and others where you might need programmer help. Just as
-ffast-math is useful, so might -fmerge-functions or
__attribute__((mergeable)), even if that resulted in non-standard
handling of function pointers.
We could certainly do this in the context of LTO. It might be a nice
trick to do it in the general GCC back end, and then it would work both
for a single module and for LTO; both cases are useful. It's also
possible to do some of this in the front end; the paper I wrote talked
about how you could notice that a particular template did not make any
particular use of the type of the argument (i.e,. that "T*" was treated
the same, independent of "T").
I think that *all* of these places might be useful eventually: in the
front end, the back end, and the linker. I'd be happy to start
anywhere. :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
gcc-4.1-20060915 is now available
Snapshot gcc-4.1-20060915 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060915/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 116981 You'll find: gcc-4.1-20060915.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060915.tar.bz2 C front end and core compiler gcc-ada-4.1-20060915.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060915.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060915.tar.bz2 C++ front end and runtime gcc-java-4.1-20060915.tar.bz2 Java front end and runtime gcc-objc-4.1-20060915.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060915.tar.bz2The GCC testsuite Diffs from 4.1-20060908 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
Type yielded by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD hook?
I'm trying to add a hook for aligning vectors for loads. I'm using the altivec rs6000 code as a baseline. However, the instruction is like the iwmmxt_walign instruction in the ARM port; it takes a normalish register and uses the bottom bits... it doesn't use a full-width vector. GCC complains when my builtin pointed to by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD yields a QImode result, because it has no way of converting that to the vector moe it is expecting. I think the altivec side would have a similar problem, as the expected RTX output RTX is: (reg:V8HI 131 [ vect_var_.2540 ]) but it changes that to: (reg:V16QI 160) for the VLSR instruction. V16QImode is what VPERM expects, and I think since V8HI and V16QI mode are the same size everyone is happy. Is there a way to tell GCC what the type of the TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD should be? Looking at http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gccint/Addressing-Modes.html#Addressing-Modes it reads like it must merely match the last operand of the vec_realign_load_ pattern. -- Why are ``tolerant'' people so intolerant of intolerant people?
Is PR21674 really fixed for gcc 4.2?
I noticed that at least on Darwin PPC -m32 and -m64 we have been passing the test cases... XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test in the libstdc++ testsuite. From what I see in bugzilla for PR21674, it seems that it should be fixed on gcc trunk, right? Shouldn't the xfail line be dropped now from those two test cases for the gcc 4.2 release? Jack
Re: Merging identical functions in GCC
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote: Ian Lance Taylor wrote: >I think Danny has a 75% implementation based on hashing the RTL for a >section and using that to select the COMDAT section signature. I don't think this is a good idea. With different compiler options the same RTL can generate different assembly instructions. Consider the case of compiling the same function multiple times with different names and different CPU architectures selected. You'd actually want the linker to merge the functions that ended up having the same assembly, but not the ones with the same RTL but different assembly. So basically you are saying if you don't know what you are doing, or know you don't want to use it, you shouldn't be using it. I'd agree with that :) (The current hash actually takes into account compiler options as a starting value for the hash, btw!)
Re: Merging identical functions in GCC
Ross Ridge writes: >I don't think this is a good idea. With different compiler options the >same RTL can generate different assembly instructions. Consider the case >of compiling the same function multiple times with different names and >different CPU architectures selected. You'd actually want the linker >to merge the functions that ended up having the same assembly, but not >the ones with the same RTL but different assembly. Daniel Berlin writes: >So basically you are saying if you don't know what you are doing, or >know you don't want to use it, you shouldn't be using it. No, and I can't see how how you've came up with such an abusurd misintepretation of what I said. As I said clearly and explicity, the example I gave was where you'd want to use function merging. >The current hash actually takes into account compiler options as a >starting value for the hash, btw!) Well, then that brings up the other problem I have with this, figuring out exactly which options and which parts of the RTL should be hashed seems to be too error prone. I think this is best done by linker which can much more reliably compare the contents of functions to see if they are the same. Ross Ridge
Re: Merging identical functions in GCC
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote: Ross Ridge writes: >I don't think this is a good idea. With different compiler options the >same RTL can generate different assembly instructions. Consider the case >of compiling the same function multiple times with different names and >different CPU architectures selected. You'd actually want the linker >to merge the functions that ended up having the same assembly, but not >the ones with the same RTL but different assembly. Daniel Berlin writes: >So basically you are saying if you don't know what you are doing, or >know you don't want to use it, you shouldn't be using it. No, and I can't see how how you've came up with such an abusurd misintepretation of what I said. As I said clearly and explicity, the example I gave was where you'd want to use function merging. Whatever. Why would you turn on function merging if you are trying to specifically get the compiler to produce different code for your functions than it did before? Not that it matters, since it won't do it anyway since it takes compiler options into account. As an FYI, you already have this situation with linkonce functions. >The current hash actually takes into account compiler options as a >starting value for the hash, btw!) Well, then that brings up the other problem I have with this, figuring out exactly which options and which parts of the RTL should be hashed seems to be too error prone. Error prone? We do it already, and rely on it to perform value numbering on RTL. Conservatively coming up with correct answers to determining the value pieces of RTL compute is neither error prone, nor difficult. I think this is best done by linker which can much more reliably compare the contents of functions to see if they are the same. No it can't. It has no idea what a function consists of other than a bunch of bytes, in pretty much all cases. It certainly shouldn't be disassembling the functions and comparing them to see if they will always generate the same results and have the same side effects. Even if it could, it would take the same kind of value numbering optimization infrastructure to get good results. Stupid byte comparisons of functions generally won't save you anything truly interesting.
