Re: Scheduling x86 dispatch windows
> It would help compilation time a little bit, but generating the > assembly code and running the entire assembler is a fairly small > percentage of the overall compilation time--e.g., 3%. It's worth > doing a fair amount of work to speed up compilation by 3%, but linking > the assembler into gcc would be an enormous amount of work. I would Curious -- why do you think it would be that much work? I admit I haven't looked into gas code, but naively it can't be all that difficult to e.g. run gas as a thread and pass the text input through some shared memory buffer? That would likely not speed up thinks too much, but it could be a starting for more short cuts. -Andi
Re: Scheduling x86 dispatch windows
Quoting Andi Kleen : I admit I haven't looked into gas code, but naively it can't be all that difficult to e.g. run gas as a thread and pass the text input through some shared memory buffer? If you are generating text anyway, there should be little difference to the existing -pipe option - at least on operating systems that can handle processes efficiently.
Re: Issue with LTO/-fwhole-program
On 12/06/2010 16:52, Richard Guenther wrote: On Sat, Jun 12, 2010 at 3:32 PM, David Brown wrote: Ian Lance Taylor wrote: Manuel López-Ibáñez writes: This also means that linking your program with non-LTO+whole-program code may lead to miscompilations without any warning, which is really bad. I don't think it is a reasonable limitation and we will get bad press when programs start breaking for users. They won't care (and they won't even listen) about the reasons. The conclusion will be: LTO is broken in GCC, and just use another compiler. The limitation isn't all that bad. If you want to use -fwhole-program, I think the basic rule is this: compile all your code with -flto, and don't define variables or functions which are referenced by any code which is not yours. I think adding a warning for this case would be great, if we can figure out how to do it. But I also think that a clear statement in the documentation will avoid most user problems. Ian To me, this sounds like you are safe as long as you stick to the "one definition rule". This is a requirement for C++ - the original example with "int v" definitions in two files would be illegal in C++, while it is legal in C. Correct. In failure mode with -fno-common you would get a linker error instead of silent miscompiles. I work as an embedded systems developer, especially for small microcontrollers. In my programs, the huge majority of code is written by me - I don't even make much use of standard libraries (other than gcc's target support libraries, of course). So if my questions or comments here sound a bit silly, it's just that I don't normally have to work with code from multiple sources. I use the -fno-common flag in all my compilations - I see it as a mistake to have uninitialised global data defined in more than one place at a time. I can see that such "common" segment data can occur in legacy code, but is it much used in modern programming? I would think that while many C programmers (myself included) prefer to stick to C rather than C++ for many reasons, many also like to take some of the good ideas from C++. Just as many features of C++ have become part of newer C standards, so I think have some of the ideas of clearer structure and modularisation - including the clear separation of interface (headers) and implementation (c files), and appropriate use of "extern" and "static". Such programs should compile cleanly with -fno-common. If -flto were to activate the -fno-common flag, would that then catch these potential problems with a linker error? This will give some false positives, of course, but it is better to produce suboptimal code (i.e., disable LTO) than to risk producing wrong code. If it turns out that common data is so common that it must be possible to enable LTO with common data, then this could perhaps be reduced to a warning when LTO and common data are used together, or with a specific "-fi-know-what-im-doing" flag to disable the no-common errors. Assuming I'm correct here, then perhaps there could be a warning or error message that is triggered by breaking the ODR, and which could be enabled automatically by the -flto flag. Perhaps existing checking mechanisms from C++ can be used here. It's not easy without using the gold linker-plugin as we do not see the other definition. With using the gold linker-plugin we can detect the situation and do the right thing (as proposed by the patches from Binfeng). Richard. David
Re: [Patch,Fortran,Committed] Re: Incorrect format of copyright statement for Fortran manuals
On Mon, 7 Jun 2010, Tobias Burnus wrote: >> It has been reported via the FSF that 'gfortran.info' is copyrighted by >> the FSF '1999-2008', although it should be under the form '1999, 2000, >> [other years], 2008'. > Fixed in Rev. 160390 using the attached patch. Thanks, Tobias! Any chance you could make the similar change for GCC 4.5 as our active release as well? Gerald
Re: Scheduling x86 dispatch windows
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote: > Quoting Andi Kleen : >> I admit I haven't looked into gas code, but naively it can't >> be all that difficult to e.g. run gas as a thread and >> pass the text input through some shared memory buffer? > > If you are generating text anyway, there should be little difference to > the existing -pipe option - at least on operating systems that can handle > processes efficiently. Yes but you can't easily pass data back, like accurate instruction lengths. -Andi
how to get instruction codes in gcc passes?
Hi all.
(I have never used these maillists before. Sorry if something wrong here.)
I am newbie in gcc and I need some help.
I am performing some research work in theme of code optimization.
Now I have to write my own optimization pass for gcc. And in this pass
I need to get the instruction codes of the resulting assemble code.
I put my pass just before the "NEXT_PASS (pass_final);" in
init_optimization_passes function. So I think that asm instructions
are almost ready when my pass starts its work.
This pass is already inserted into the gcc code and can be started.
The gcc is compiled. And I can see my debug stuff in especially
generated file when the gcc works.
Actually I have no useful code yet, but I just want to get some
information for starting the developing.
For the beginning I want to do something like this:
for (insn = get_insns() ; insn ; insn = NEXT_INSN(insn))
{
int code = ...; //I need help in this line!!!
myDebugOutputShowCode(++i, code);
}
I.e. I just want to see the whole list of code of instructions. Like
assembler listing.
Can you help me and give some advices how to do it?
I had a look at some *.md files in gcc sources, but did not found any
source of codes of assembler instructions. How does the gcc generates
the binary file? Where can it get the binary representation of asm
instruction?
Where is it described that "nop" is "0F 1F" value for x86 architecture
and so on?
Thanks for any help.
Re: Scheduling x86 dispatch windows
Quoting Andi Kleen :
On Sun, Jun 13, 2010 at 07:14:03AM -0400, Joern Rennecke wrote:
Quoting Andi Kleen :
I admit I haven't looked into gas code, but naively it can't
be all that difficult to e.g. run gas as a thread and
pass the text input through some shared memory buffer?
If you are generating text anyway, there should be little difference to
the existing -pipe option - at least on operating systems that can handle
processes efficiently.
Yes but you can't easily pass data back, like accurate instruction lengths.
We were just talking about saving time by reducing the work of the
assembler, which Ian said takes about 3% of the compilation time.
So in that context, -pipe should be similar to text buffer thread
communication.
If you want to make exact length information available to the scheduler,
text buffers are not all that easy to use - the assembly output of the
compiler is so far only done in final, and things like register allocation
(for sched1), machine_dependent_reorg, peepholes, final_{pre_}scan_insn,
assembler dialects, and functional output templates that rely on some data
to be computed by prologue code or similar are in the way of getting a
string suitable for the assembler during scheduling.
And if you have to audit and/or patch every pattern of your port to verify
that it'll work in a different context, you might as well fix the length
information.
An even if you have a suitable text for the assembler, to link the compiler
with the assembler requires to merge to two complex build systems, and
resolve symbol name clash issues.
Using socketpair / fork / exec for the interface would restrict portability
to the new feature to host operating systems that implement these system
calls, but you wouldn't have to worry about having to merge the compiler
with the assembler.
Or if you have a bit more (developer & CPU) time, you can use a client/server
interface with AF_UNIX / AF_INET sockets. Or you could go for SYSV shared
memory.
All of these Inter Process Communication mechanisms with nice autoconf and
configure option scripting together will likely be only a fraction of the
hassle of trying to merge gcc and gas and to push the patches for that
monster upstream.
For starters, gas and gcc have different maintainers, asynchronous
release schedules, and reside in different repositories with different
version
control systems.
Using the opcodes directory directly could be slightly saner, if it
were not for the fact that there are about as many different interfaces as
there are different ports.
Alhough the cgen ports have some things in common, there is always some
port-specific glue. And there are still plenty of non-cgen ports, too.
Re: how to get instruction codes in gcc passes?
On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote:
> Hi all.
> (I have never used these maillists before. Sorry if something wrong here.)
>
> I am newbie in gcc and I need some help.
>
> I am performing some research work in theme of code optimization.
> Now I have to write my own optimization pass for gcc. And in this pass
> I need to get the instruction codes of the resulting assemble code.
>
> I put my pass just before the "NEXT_PASS (pass_final);" in
> init_optimization_passes function. So I think that asm instructions
> are almost ready when my pass starts its work.
> This pass is already inserted into the gcc code and can be started.
> The gcc is compiled. And I can see my debug stuff in especially
> generated file when the gcc works.
> Actually I have no useful code yet, but I just want to get some
> information for starting the developing.
>
> For the beginning I want to do something like this:
> for (insn = get_insns() ; insn ; insn = NEXT_INSN(insn))
> {
> int code = ...; //I need help in this line!!!
> myDebugOutputShowCode(++i, code);
> }
>
> I.e. I just want to see the whole list of code of instructions. Like
> assembler listing.
>
> Can you help me and give some advices how to do it?
> I had a look at some *.md files in gcc sources, but did not found any
> source of codes of assembler instructions. How does the gcc generates
> the binary file? Where can it get the binary representation of asm
> instruction?
> Where is it described that "nop" is "0F 1F" value for x86 architecture
> and so on?
GCC does not have an integrated assembler and only outputs
assembler source. At the point above you still have RTXen
where you can query INSN_CODE to see what instruction from
the machine description was matched. In the define_insns
there are patterns for generating the assembler source instruction.
Richard.
> Thanks for any help.
>
Re: how to get instruction codes in gcc passes?
On Sun, Jun 13, 2010 at 6:38 PM, Richard Guenther
wrote:
> On Sun, Jun 13, 2010 at 4:29 PM, Ilya K wrote:
>> Hi all.
>> (I have never used these maillists before. Sorry if something wrong here.)
>>
>> I am newbie in gcc and I need some help.
>>
>> I am performing some research work in theme of code optimization.
>> Now I have to write my own optimization pass for gcc. And in this pass
>> I need to get the instruction codes of the resulting assemble code.
>>
>> I put my pass just before the "NEXT_PASS (pass_final);" in
>> init_optimization_passes function. So I think that asm instructions
>> are almost ready when my pass starts its work.
>> This pass is already inserted into the gcc code and can be started.
>> The gcc is compiled. And I can see my debug stuff in especially
>> generated file when the gcc works.
>> Actually I have no useful code yet, but I just want to get some
>> information for starting the developing.
>>
>> For the beginning I want to do something like this:
>> for (insn = get_insns() ; insn ; insn = NEXT_INSN(insn))
>> {
>> int code = ...; //I need help in this line!!!
>> myDebugOutputShowCode(++i, code);
>> }
>>
>> I.e. I just want to see the whole list of code of instructions. Like
>> assembler listing.
>>
>> Can you help me and give some advices how to do it?
>> I had a look at some *.md files in gcc sources, but did not found any
>> source of codes of assembler instructions. How does the gcc generates
>> the binary file? Where can it get the binary representation of asm
>> instruction?
>> Where is it described that "nop" is "0F 1F" value for x86 architecture
>> and so on?
>
> GCC does not have an integrated assembler and only outputs
> assembler source. At the point above you still have RTXen
> where you can query INSN_CODE to see what instruction from
> the machine description was matched. In the define_insns
> there are patterns for generating the assembler source instruction.
>
> Richard.
>
>> Thanks for any help.
>>
>
OK. No low-level instruction codes in gcc.
I found the definitions of instructions in i386.dm (thanks for this advice):
(define_insn "nop"
[(const_int 0)]
""
"nop"
[(set_attr "length" "1")
(set_attr "length_immediate" "0")
(set_attr "modrm" "0")])
So, the gcc only knows that some specific internal representation
should be generated as "nop" string, right?
And who is generating the binary file from the asm file? Does gcc call
the external program? What the name of this program? Or the sources I
need can be found inside the gcc directory?
I think that if there are no such instruction-code table inside gcc, I
can build my own version of it inside my pass. But I need the sources
of some utility which knows how to convert "nop" string into the
binary number. Where can I get it?
Fwd: gcc-4.5.0 Success Story with Freecell Solver
-- Forwarded Message -- Subject: gcc-4.5.0 Success Story with Freecell Solver Date: Sunday 13 Jun 2010, 17:21:00 From: Shlomi Fish To: Freecell Solving Discussions Executive summary: I have built installed gcc-4.5.0 and after Freecell Solver ran faster, after I compiled it with gcc-4.5.0. I've recently gone over my LWN.net ( http://lwn.net/ ) backlog and saw this feature about gcc-4.5.0: http://lwn.net/Articles/387122/ It mentioned the "Link-Time Optimisation" feature (using the -flto flag) which piqued my interest on how well it will work for Freecell Solver ( http://fc-solve.berlios.de/ ). So I set out to try it out. I downloaded gcc-4.5.0 (which took a while due to the large archive size and problems in finding a fast mirror), unpacked it, and read the INSTALL/ notes. After running the appropriate ./configure call, I typed make and waited. For many hours. But it built up successfully, and I was able to install it. I used the following command, which I've stored in a shell script: [shell] #!/bin/bash ~/Download/unpack/prog/gcc/gcc-4.5.0/configure \ --prefix="$HOME"/apps/prog/gcc-4.5.0 [/shell] After installing gcc, I patched fc-solve's CMakeLists.txt to check for the availability of the -flto flag and also enable it at link-time. This went well, and I benchmarked Freecell Solver after being compiled with it. The end result was that it made the standard Microsoft FreeCell 32,000 boards benchmark take 91.0577080249786 seconds instead of 93.6305630207062 seconds , an improvement of over 2.5 seconds and of roughly 2.75%. (Going down to 351.43 boards per second). So it seems like an impressive gain. That was on my Pentium 4-2.4 GHz stationary machine running Mandriva Linux Cooker. Then I set out to do the same on my newer Core Duo x86-64 laptop also running Mandriva Cooker. I installed gcc this time restricting the --enable-languages to c and c++ so it will take less time. After installing it in a prefix, I realised CMake could not find its -flto flag . As it turns out, it was not enabled because gcc-4.5.0 could not find libelf-devel. Installing it resolved it. The difference there was less dramatic than on my P4 machine - about 0.5 seconds were saved out of about 35 seconds running time. However, in general, I'm happy with the results. Thanks to all the gcc developers for their hard work on making gcc better, including improving the performance of many programs. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Original Riddles - http://www.shlomifish.org/puzzles/ God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply . - -- - Shlomi Fish http://www.shlomifish.org/ Optimising Code for Speed - http://shlom.in/optimise God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply .
Re: how to get instruction codes in gcc passes?
On 13/06/2010 16:01, Ilya K wrote: > And who is generating the binary file from the asm file? Does gcc call > the external program? What the name of this program? Or the sources I > need can be found inside the gcc directory? Gcc calls out to the assembler that it detects (or is instructed to use) at configure time; generally that would be GAS from binutils, but GCC also works with the native assembler on several platforms. > I think that if there are no such instruction-code table inside gcc, I > can build my own version of it inside my pass. But I need the sources > of some utility which knows how to convert "nop" string into the > binary number. Where can I get it? Well, binutils (http://sourceware.org/binutils) has assemblers for most targets, but it would be a *big* job building parts of it into GCC. Even then, you might have a problem; what if your builtin assembler chooses different prefixes or encodings compared to the external one, or optimises differently in some way? What exact use would it be to you having the opcode bytes known during an optimisation pass? There may be a better/easier way to do whatever it is you're trying to do. cheers, DaveK
Re: Scheduling x86 dispatch windows
Andi Kleen writes: > [...] > Yes but you can't easily pass data back, like accurate instruction lengths. Wouldn't it be too late by then? Or are you imagining having the compiler pass trial data to the assembler to create a feedback loop? - FChE
Re: how to get instruction codes in gcc passes?
On Sun, Jun 13, 2010 at 7:38 PM, Dave Korn wrote: ... > What exact use would it be to you having the opcode bytes known during an > optimisation pass? There may be a better/easier way to do whatever it is > you're trying to do. > > cheers, > DaveK > My main aim is to build platform-dependent optimization based on the minimizing of hamming distance between the instructions. So I need the platform-specific information like instruction codes. Well, may be I should to try to put it into GAS, not into the gcc. I just never looked over these assemblers. I thought that if gcc already have the base of optimizations then this will be a best place to put another one. I do not know now if these assembler tools have a room for optimization. Ilya K
Re: Scheduling x86 dispatch windows
On Jun 13, 2010, at 7:35 AM, Joern Rennecke wrote: > An even if you have a suitable text for the assembler, to link the compiler > with the assembler requires to merge to two complex build systems, and > resolve symbol name clash issues. Not trying to be inflammatory, but if you guys are really serious about doing this, you could consider using the LLVM integrated assembler. It is built as a library and is easily separable from the code generator (codegen depends on the assembler, not the other way around). It would be much much simpler to integrate than the binutils assembler. Some information is here: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html It currently supports darwin x86 quite well. ELF/PECOFF and ARM support are in active development. It sped up clang by ~10% at -O0 -g. -Chris
[inliner] g++ -O[123] generates undefined symbol
Trunk g++/x86/160655 with -O0 compile test w/o errors, but with
-O[123] generates undefined symbol
--> cat 2010_06_13.cpp
namespace FOO {
template
class A
{
public:
A(char *pMemMgr = 0);
void Enum();
virtual void OnProv() = 0;
virtual ~A() { }
};
typedef A B;
template
inline A::A(char *pMemMgr)
{
}
template
inline void A::Enum ()
{
OnProv ();
}
} // namespace FOO
class C {};
class D: public C, public FOO::B {
public:
void OnProv() {}
};
void aaa()
{
D x;
x.Enum();
}
--> g++ -O1 -c 2010_06_13.cpp && nm -uAC 2010_06_13.o | grep OnProv
2010_06_13.o: U FOO::A::OnProv()
--> g++ -O0 -c 2010_06_13.cpp && nm -uAC 2010_06_13.o | grep OnProv
-->
--> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/i686-redhat-linux/4.6.0/lto-wrapper
Target: i686-redhat-linux
Configured with: ../gcc-current/configure
--prefix=/usr/local/gcc_current --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=yes --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-languages=c,c++ --with-ppl
--with-cloog --with-tune=generic --with-arch=i686
--build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs : (reconfigured)
../gcc-current/configure --prefix=/usr/local/gcc_current
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=yes --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++ --with-ppl --with-cloog --with-tune=generic
--with-arch=i686 --build=i686-redhat-linux --enable-lto
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.6.0 20100612 (experimental) [trunk revision 160655] (GCC)
Need i file a PR?
Thanks,
Dmitry
Re: Issue with LTO/-fwhole-program
David Brown writes: > If -flto were to activate the -fno-common flag, would that then catch > these potential problems with a linker error? We could perhaps do that for C/C++ code, but Fortran relies on common symbols. Ian
Re: how to get instruction codes in gcc passes?
Ilya K writes: > My main aim is to build platform-dependent optimization based on the > minimizing of hamming distance between the instructions. Take a look at http://code.google.com/p/mao/ . Ian
Re: Scheduling x86 dispatch windows
On Sat, Jun 12, 2010 at 8:15 AM, H.J. Lu wrote: > On Fri, Jun 11, 2010 at 3:42 PM, Quentin Neill > wrote: >> On Thu, Jun 10, 2010 at 5:23 PM, H.J. Lu wrote: >>> [snip] >>> x86 assembler isn't an optimizing assembler. -mtune only does >>> instruction selection. What you are proposing sounds like an optimizing >>> assembler to me. Are we going to support scheduling, macro, ...? >>> -- >>> H.J. >> >> Just to clarify, we are not doing scheduling or macros. The >> assembler already supported alignment and padding using .align and >> friends, which can be from the compiler and from hand-written >> assembly. >> >> Now we are seeing more complex alignment rules that are not as simple >> as it used to be for the older hardware. It will be almost impossible >> for an assembly programmer to insert the right directives, not to >> mention any change might invalidate previous alignments. Assembly >> programmers will be out of luck (that is, unless the compiler becomes >> the assembler). > > If you can find a way to help assembly programmers via new directives, > it is great. GNU x86 assembler should just translate assembly code > into binary code. The output of "objdump -d" should be identical > to the input assembly. > > We shouldn't turn GNU x86 assembler into an optimizing assembler. > Next people may ask assembler to remove redundant instructions, ... > > Right now, when something goes wrong, people don't have to debug > assembler since it is very unlikely that the problem is in assembler. > When assembler starts to make changes to assembly input, we have > another place where a bug may be introduced. > >> >> The essence is we want to insert prefixes (as well as nops) according >> to certain rules known at encoding time. The mechanism implementing >> these rules can be abstracted (table driven?) and could be applicable >> to any hardware having similar features. > > Can you implement them with new directives/pseudo instructions? > I think you should take a look at http://code.google.com/p/mao/ -- H.J.
Re: how to get instruction codes in gcc passes?
On Sun, 2010-06-13 at 18:29 +0400, Ilya K wrote:
> Hi all.
> (I have never used these maillists before. Sorry if something wrong here.)
>
> I am newbie in gcc and I need some help.
>
> I am performing some research work in theme of code optimization.
> Now I have to write my own optimization pass for gcc. And in this pass
> I need to get the instruction codes of the resulting assemble code.
Why do you want to optimize the generated assembly code? AFAIK, all
optimization passes in GCC work on some intermediate representation
which is not the assembly code, and many of them work on Gimple.
What is so special for your optimization to require working at the
assembly code level specifically?
There are several good reasons to prefer optimizing in the middle end
(e.g. power of the Gimple representation, target machine
independence, ...).
BTW, you might consider using MELT http://gcc.gnu.org/wiki/MELT to code
your optimization, especially if it can be expressed at the Gimple
level.
> Where is it described that "nop" is "0F 1F" value for x86 architecture
> and so on?
This is not described in GCC. GCC emit textual assembly code. The
assembler (that is binutils, not GCC) know that nop is 0f 1f.
Cheers.
PS. I might have some details wrong; I am not very familiar with GCC
back-ends & RTL passes.
--
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 mines, sont seulement les miennes} ***
Re: Issue with LTO/-fwhole-program
On 13/06/2010 20:55, Ian Lance Taylor wrote: > David Brown writes: > >> If -flto were to activate the -fno-common flag, would that then catch >> these potential problems with a linker error? > > We could perhaps do that for C/C++ code, but Fortran relies on common > symbols. Well we shouldn't do it for plain C either, or at the very least should make it depend on the -std= option in effect, but since the code is entirely valid and legitimate C, I think we should acknowledge this is a weakness in our compiler. The original testcase is a perfectly straightforward bit of C89; there are two compatible tentative declarations of a variable of type int called "v". We don't want to have to argue that one is in fact a variable of type "int compiled with LTO" in order to back-justify some argument that they are not the same and this example violates some (vague and not standard-specified) C equivalent of the ODR. cheers, DaveK
Re: how to get instruction codes in gcc passes?
On 13/06/2010 20:57, Ian Lance Taylor wrote: > Ilya K writes: > >> My main aim is to build platform-dependent optimization based on the >> minimizing of hamming distance between the instructions. > > Take a look at http://code.google.com/p/mao/ . Or in binutils, LD's relaxation infrastructure might be usable to this end. But I think if you want something so platform dependent as to care about the bitpatterns of opcodes, it almost certainly ought to live in the assembler or linker rather than then compiler. cheers, DaveK
Re: Issue with LTO/-fwhole-program
On Sun, 13 Jun 2010, Dave Korn wrote: > On 13/06/2010 20:55, Ian Lance Taylor wrote: > > David Brown writes: > > > >> If -flto were to activate the -fno-common flag, would that then catch > >> these potential problems with a linker error? > > > > We could perhaps do that for C/C++ code, but Fortran relies on common > > symbols. > > Well we shouldn't do it for plain C either, or at the very least should make > it depend on the -std= option in effect, but since the code is entirely valid > and legitimate C, I think we should acknowledge this is a weakness in our > compiler. The original testcase is a perfectly straightforward bit of C89; > there are two compatible tentative declarations of a variable of type int > called "v". We don't want to have to argue that one is in fact a variable of This is not valid standard C; you can have two tentative definitions in the same translation unit, but not in different translation units. Allowing commons is listed as a common extension in C90 G.5.11. -- Joseph S. Myers jos...@codesourcery.com
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On Mon, 7 Jun 2010, Jonathan Wakely wrote: > Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn I ran this script, and verified that it runs daily, 55 minutes after midnight UTC. Alas, it seems the script does not lead to the desired result -- the libstdc++ onlinedocs/ pages appear stale. > >> And wouldn't it be appropriate to remove doc/xml/gnu/fdl-1.2.xml now >> that you have added fdl-1.3.xml? > Possibly. We still have gpl-2.0.xml there, which doesn't seem to be > included. I followed that example. If you are not using GPL 2.0 nor FDL 1.2 anymore in libstdc++ (and we should not be using these two anymore in all of GCC), we shold remove them. Would you mind doing that or should I give it a try? Gerald
Re: Issue with LTO/-fwhole-program
Dave Korn wrote: On 13/06/2010 20:55, Ian Lance Taylor wrote: David Brown writes: If -flto were to activate the -fno-common flag, would that then catch these potential problems with a linker error? We could perhaps do that for C/C++ code, but Fortran relies on common symbols. Well we shouldn't do it for plain C either, or at the very least should make it depend on the -std= option in effect, but since the code is entirely valid and legitimate C, I think we should acknowledge this is a weakness in our compiler. The original testcase is a perfectly straightforward bit of C89; there are two compatible tentative declarations of a variable of type int called "v". We don't want to have to argue that one is in fact a variable of type "int compiled with LTO" in order to back-justify some argument that they are not the same and this example violates some (vague and not standard-specified) C equivalent of the ODR. cheers, DaveK I agree that banning common symbols is not a complete solution. But perhaps it may be a partial solution until some more complete solution is found and implemented? How about having a warning flag -Wcommon-lto which will produce a warning if LTO is used along with common data, and which is enabled by default by -flto? For code that does not use common symbols, everything works as expected and the user gets LTO'ed code. But if the code /does/ use common symbols, you get a warning that the code may be incorrect if a common symbol is declared in both LTO and non-LTO object files. It is then up to the user to ignore the warning, or fix the common symbols. This is not a complete fix - ideally, LTO should work fine even with common symbols. And failing that, the warning (or error) message should only come if there really is a conflict, rather than just a potential conflict. But I would think that a check like this is a relatively simple feature, and would add an extra level of safety to LTO. Incidentally, the original poster used -fwhole-program. Is this conflict only an issue when the -fwhole-program flag is used? If that's the case, then the warning could be conditional on that flag too, meaning even rarer circumstances when false positives would be issued. David
onlinedocs/libstdc++ apperas stale (was: [doc,patch] Move from GFDL 1.2 to GFDL 1.3)
On Mon, 14 Jun 2010, Gerald Pfeifer wrote: >> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn > I ran this script, and verified that it runs daily, 55 minutes after > midnight UTC. Alas, it seems the script does not lead to the desired > result -- the libstdc++ onlinedocs/ pages appear stale. Got it! % ll /www/gcc/htdocs/onlinedocs/libstdc++ -rw-r--r-- 1 gccadmin gcc 4434 Jun 12 00:55 api.html -rw-r--r-- 1 gccadmin gcc 1539 Jun 13 22:07 api.html.gz -rw-r--r-- 1 gccadmin gcc 1786 Apr 22 00:55 bk02.html -rw-r--r-- 1 gccadmin gcc698 Jun 13 22:07 bk02.html.gz -rw-r--r-- 1 gccadmin gcc 1762 Apr 22 00:55 bk03.html -rw-r--r-- 1 gccadmin gcc692 Jun 13 22:07 bk03.html.gz drwxr-sr-x 16 bkoz gcc 4096 Apr 12 2008 dated drwxrwsr-x 3 pme gcc 4096 Jun 13 22:07 ext -rw-r--r-- 1 gccadmin gcc 66038 Jun 12 00:55 faq.html -rw-r--r-- 1 gccadmin gcc 17129 Jun 13 22:07 faq.html.gz -rw-r--r-- 1 bkoz gcc994 Oct 5 2009 index.html -rw-r--r-- 1 gccadmin gcc511 Jun 13 22:07 index.html.gz The script places up-to-date .html.gz files in the web infrastructure, alas we do have older .html there -- and our web server is happy to serve those over the compressed ones. In any case, we surely do not want to have _inconsistent_ versions of the same contents there. I guess what we should rather do is copying over the .html files from the temporary directory into the web tree and then do the compressing in the web tree. But I assume you guys on the libstdc++ side are a lot more familiar with this, so it's your call. There may be other ideas, just what we currently have doesn't seem to work. Gerald
gcc-4.3-20100613 is now available
Snapshot gcc-4.3-20100613 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100613/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 160689 You'll find: gcc-4.3-20100613.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100613.tar.bz2 C front end and core compiler gcc-ada-4.3-20100613.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100613.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100613.tar.bz2 C++ front end and runtime gcc-java-4.3-20100613.tar.bz2 Java front end and runtime gcc-objc-4.3-20100613.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100613.tar.bz2The GCC testsuite Diffs from 4.3-20100606 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Re: Issue with LTO/-fwhole-program
On 13/06/2010 23:22, David Brown wrote: > I agree that banning common symbols is not a complete solution. But > perhaps it may be a partial solution until some more complete solution > is found and implemented? > > How about having a warning flag -Wcommon-lto > Incidentally, the original poster used -fwhole-program. Is this > conflict only an issue when the -fwhole-program flag is used? If that's > the case, then the warning could be conditional on that flag too, > meaning even rarer circumstances when false positives would be issued. Yes; it's not really a problem that is related to common symbols at all, it's basically to do with mixing LTO and non-LTO objects when -fwhole-program, if I understand right. cheers, DaveK
Re: onlinedocs/libstdc++ appears stale
On Mon, 14 Jun 2010, Gerald Pfeifer wrote: >>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn > The script places up-to-date .html.gz files in the web infrastructure, > alas we do have older .html there -- and our web server is happy to > serve those over the compressed ones. > > In any case, we surely do not want to have _inconsistent_ versions of > the same contents there. Any objection to me running the following find . -name '*.html' | while read f; do g="$f.gz" if [ -e "$g" ] && [ "$f" -ot "$g" ]; then echo "$f is older than $g and should be removed." fi done where the echo is replaced by an "rm $f"? Currently that has 348 hits in /www/gcc/htdocs/onlinedocs/libstdc++. Gerald
Re: Issue with LTO/-fwhole-program
On 13/06/2010 23:20, Joseph S. Myers wrote: > On Sun, 13 Jun 2010, Dave Korn wrote: > >> On 13/06/2010 20:55, Ian Lance Taylor wrote: >>> David Brown writes: >>> If -flto were to activate the -fno-common flag, would that then catch these potential problems with a linker error? >>> We could perhaps do that for C/C++ code, but Fortran relies on common >>> symbols. >> Well we shouldn't do it for plain C either, or at the very least should make >> it depend on the -std= option in effect, but since the code is entirely valid >> and legitimate C, I think we should acknowledge this is a weakness in our >> compiler. The original testcase is a perfectly straightforward bit of C89; >> there are two compatible tentative declarations of a variable of type int >> called "v". We don't want to have to argue that one is in fact a variable of > > This is not valid standard C; Not valid *which standard* C? > you can have two tentative definitions in > the same translation unit, but not in different translation units. > Allowing commons is listed as a common extension in C90 G.5.11. So your objection is that it *is* valid after all? I'm not following. As far as I remember that sort of thing, ropey though it seems nowadays, was always an accepted part of K'n'R C, which I thought was what C89 aimed to formalize. cheers, DaveK
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On 13 June 2010 23:22, Gerald Pfeifer wrote: > On Mon, 7 Jun 2010, Jonathan Wakely wrote: >> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn > > I ran this script, and verified that it runs daily, 55 minutes after > midnight UTC. Alas, it seems the script does not lead to the desired > result -- the libstdc++ onlinedocs/ pages appear stale. Thanks for trying, I think Benjamin will have to take a look and see what's wrong. >>> And wouldn't it be appropriate to remove doc/xml/gnu/fdl-1.2.xml now >>> that you have added fdl-1.3.xml? >> Possibly. We still have gpl-2.0.xml there, which doesn't seem to be >> included. I followed that example. > > If you are not using GPL 2.0 nor FDL 1.2 anymore in libstdc++ (and we > should not be using these two anymore in all of GCC), we should remove > them. Would you mind doing that or should I give it a try? I can do that, assuming no objections from the other maintainers. Jonathan
Re: Issue with LTO/-fwhole-program
On Mon, 14 Jun 2010, Dave Korn wrote: > On 13/06/2010 23:20, Joseph S. Myers wrote: > > On Sun, 13 Jun 2010, Dave Korn wrote: > > > >> On 13/06/2010 20:55, Ian Lance Taylor wrote: > >>> David Brown writes: > >>> > If -flto were to activate the -fno-common flag, would that then catch > these potential problems with a linker error? > >>> We could perhaps do that for C/C++ code, but Fortran relies on common > >>> symbols. > >> Well we shouldn't do it for plain C either, or at the very least should > >> make > >> it depend on the -std= option in effect, but since the code is entirely > >> valid > >> and legitimate C, I think we should acknowledge this is a weakness in our > >> compiler. The original testcase is a perfectly straightforward bit of C89; > >> there are two compatible tentative declarations of a variable of type int > >> called "v". We don't want to have to argue that one is in fact a variable > >> of > > > > This is not valid standard C; > > Not valid *which standard* C? Any standard C. It is not valid C90 or C99. > > you can have two tentative definitions in > > the same translation unit, but not in different translation units. > > Allowing commons is listed as a common extension in C90 G.5.11. > > So your objection is that it *is* valid after all? I'm not following. As It is a common extension, not ISO C. LTO of course should handle -fcommon, -fno-common, mixtures of them and the "common" and "nocommon" attributes, as part of handling all of GNU C. > far as I remember that sort of thing, ropey though it seems nowadays, was > always an accepted part of K'n'R C, which I thought was what C89 aimed to > formalize. The C89 Rationale lists various models used by different implementation in this area, and the Unix model it describes as "Relaxed Ref/Def" is not the one adopted by C89. -- Joseph S. Myers jos...@codesourcery.com
Re: [doc,patch] Move from GFDL 1.2 to GFDL 1.3
On 14 June 2010 00:23, Jonathan Wakely wrote: > On 13 June 2010 23:22, Gerald Pfeifer wrote: >> On Mon, 7 Jun 2010, Jonathan Wakely wrote: >>> Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn >> >> I ran this script, and verified that it runs daily, 55 minutes after >> midnight UTC. Alas, it seems the script does not lead to the desired >> result -- the libstdc++ onlinedocs/ pages appear stale. > > Thanks for trying, I think Benjamin will have to take a look and see > what's wrong. Ah, I've just seen your followup mail :-)
Re: onlinedocs/libstdc++ appears stale
On 13 June 2010 23:56, Gerald Pfeifer wrote: > On Mon, 14 Jun 2010, Gerald Pfeifer wrote: Thanks, see /home/gccadmin/scripts/update_web_docs_libstdcxx_svn >> The script places up-to-date .html.gz files in the web infrastructure, >> alas we do have older .html there -- and our web server is happy to >> serve those over the compressed ones. >> >> In any case, we surely do not want to have _inconsistent_ versions of >> the same contents there. > > Any objection to me running the following > > find . -name '*.html' | while read f; do > g="$f.gz" > if [ -e "$g" ] && [ "$f" -ot "$g" ]; then > echo "$f is older than $g and should be removed." > fi > done > > where the echo is replaced by an "rm $f"? > > Currently that has 348 hits in /www/gcc/htdocs/onlinedocs/libstdc++. That seems like the right thing to do. I think it will leave some stale files in place, because the output of generating the html docs creates different filenames sometimes, so there won't be a new .gz for all the old files. Those stale files shouldn't be reachable from any fresh pages. If you could send me a list of all the files remaining under that dir after your command, I will let you know which can safely be removed because they are stale and have been replaced by a new file with a different name.
Re: Issue with LTO/-fwhole-program
Dave Korn wrote: On 13/06/2010 23:22, David Brown wrote: I agree that banning common symbols is not a complete solution. But perhaps it may be a partial solution until some more complete solution is found and implemented? How about having a warning flag -Wcommon-lto Incidentally, the original poster used -fwhole-program. Is this conflict only an issue when the -fwhole-program flag is used? If that's the case, then the warning could be conditional on that flag too, meaning even rarer circumstances when false positives would be issued. Yes; it's not really a problem that is related to common symbols at all, it's basically to do with mixing LTO and non-LTO objects when -fwhole-program, if I understand right. After doing a bit more reading and thinking, it seems to me that -fwhole-program will be used in most cases where LTO is used. You use -flto when compiling each source file, then link them with gcc with -flto and -fwhole-program. Except in the case of libraries or other files which need external symbols, you will want that combination to generate optimal code. So if this combination alone, without common symbols, is going to cause problems, then this would be a much bigger issue than if it is only triggered by common symbols. David
Re: SH optimized software floating point routines
"Naveen H. S" wrote: > Software floating point(libgcc) routines were implemented for SH in the > following links:- > http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html > http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html > http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html > > There were some discussions regarding the testing of these routines. > We had briefly tested those routines and found that they did not have > any major issues. > http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00791.html > Please let me know whether these routines can be used in SH toolchain. SH currently uses fp-bit.c implementation of soft fp which is known as a rather inefficient one. PowerPC uses a more efficient soft-fp derived from glibc. Other targets like arm, ia64, sparc and also some new targets use it. Please see config/*/t-*softfp and config/*/sfp-machine.h. We can expect the best performance from Joern's assembly soft fp, but in general the maintenance of hand crafted assembly codes will be hard. If I remember correctly, there were some arguments for this target specific one vs. generic one when soft-fp was introduced in gcc. It would be better to try soft-fp on SH and see numbers with current fp-bit, soft-fp and assembly one. If soft-fp is yet too inefficient for you, you can free to propose a complete and regtested patch for SH assembly soft fp against trunk. The original Joern's patch touched not only SH specific part but also the generic part of the compiler. The revised patch is needed to test it for various targets too. Regards, kaz
Re: Issue with LTO/-fwhole-program
David Brown writes: > After doing a bit more reading and thinking, it seems to me that > -fwhole-program will be used in most cases where LTO is used. You use > -flto when compiling each source file, then link them with gcc with > -flto and -fwhole-program. Except in the case of libraries or other > files which need external symbols, you will want that combination to > generate optimal code. So if this combination alone, without common > symbols, is going to cause problems, then this would be a much bigger > issue than if it is only triggered by common symbols. That scenario is fine. You can look back to see the problematic case posted earlier. It was a case where one file was compiled with -flto, one file was compiled without -flto, both files defined a common symbol with the same name, the object files were linked together using -flto -fwhole-program, and the gold plugin was not used. All elements are essential to recreate the problem. Ian
Re: [inliner] g++ -O[123] generates undefined symbol
Дмитрий Дьяченко writes: > Trunk g++/x86/160655 with -O0 compile test w/o errors, but with > -O[123] generates undefined symbol > Need i file a PR? It certainly looks like a bug. Please do open a bug report. Thanks. Ian
Re: SH optimized software floating point routines
Quoting Kaz Kojima : but in general the maintenance of hand crafted assembly codes will be hard. If you have a fixed feature set and pipeline, and have made sure the code is correct, no further maintenance should be required - which is more than can be said of the target port code generator, which tends to fall back in generated code performance if you have a finely tuned port and don't keep up with changes in the optimizers. AFAIK the pipeline variations in the SH still don't come close to the difference between compiler generated code and assembly code that is properly hand-optimized for the SH4-[123]00 pipelines. If soft-fp is yet too inefficient for you, you can free to propose a complete and regtested patch for SH assembly soft fp against trunk. IIRC I never finished working on some corner cases of division rounding in the SH floating-point emulation because I had no testcase (and it was not high on my agenda because there seemed to be little practical relevance). In order to test the ARCompact floating point emulations, I made a new test to check rounding of subnormal numbers during division: http://gcc.gnu.org/viewcvs/branches/arc-4_4-20090909-branch/gcc/testsuite/gcc.c-torture/execute/ieee/denorm-rand.c?limit_changes=0&view=markup&pathrev=151545 To give the code a good workout, you can up the iteration count, e.g. 1000 -> 100 . However, you probably don't want to do this with fp-bit at -O0. Also note that fp-bit.c in SVN gets the rounding wrong, you can use this patch to have a sane comparison: http://gcc.gnu.org/viewcvs/branches/arc-4_4-20090909-branch/gcc/config/fp-bit.c?limit_changes=0&r1=151545&r2=151544&pathrev=151545 FWIW, these are the associated ChangeLog entries: gcc/testsuite: 2008-04-04 J"orn Rennecke * gcc.c-torture/execute/ieee/denorm-rand.c: New file. * gcc.dg/torture/fp-int-convert.h: Avoid undefined behaviour. gcc: 2008-04-04 J"orn Rennecke * config/fp-bit.c (_fpdiv_parts): Avoid double rounding.
RE: Pseudo frame pointer register in assembly code
>> you can define a hard register HARD_FRAME_POINTER_REGNUM. Either >> way, it should not be a fixed register. In the latter case, have >> an elimination from FRAME_POINTER_REGNUM to HARD_FRAME_POINTER_REGNUM. Hi Ian, Thanks a lot for the useful suggestion. The "HARD_FRAME_POINTER_REGNUM" which was not a FIXED_REG was defined. The FRAME_POINTER_REGNUM was eliminated to HARD_FRAME_POINTER_REGNUM in the ELIMINABLE_REGS. As the frame pointer was eliminated by a hard register, undefined reference to pseudo frame pointer was solved. Thanks & Regards, Naveen
