Re: Discussion about merging Go frontend
On 29/10/2010 02:31, Ian Lance Taylor wrote: > Dave Korn >> What would be even nicer would be if we could share the same code-reader >> interface between lto and go (and the lto-plugin), thereby getting object >> format independence equally everywhere for no extra cost. > > How about this? That looks excellent, thank you! > This implements an object file reader/writer which does everything > required by LTO and gccgo. The ELF code works. I have not tested the > Mach-O and COFF code at all beyond compiling it; I hope that somebody > else can test those targets and fix them. I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be available. > With this patch, libelf is no longer needed. > > I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO > testsuite. > > This patch puts the code in libiberty, but it could equally well go in > gcc. Anybody want to make an argument one way or another? Libiberty is better for sharing with lto-plugin, I think. I sent a patch that commoned out some of the COFF-reader code into gcc/, but I only put it there because it was a single header file with no associated object file. Now there's actual code to be linked in, I think libiberty is a better choice than lto-plugin trying to share .o files from the ../gcc/ objdir. > Does the general interface look OK? > > This patch requires approval from the LTO maintainers. Also, I have a patch outstanding to COFF-ize the lto-plugin(*), so if we can get an early "OK in principle" I'll get cracking on respinning it to use this new interface. cheers, DaveK -- (*) - http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02176.html
g++ produces crazy code for STL container
I know this sounds like it might be better answered in gcc-help, but
if I am right this is a bug report.
I'm using gcc 4.5 branch, rev. 165881 (a week old), on x86-64 Linux.
This testcase is derived from a larger program. I have looked at the
assembly and was puzzled.
#include
#include
int main()
{
static const int array[] = { 1,2,3,4,5,6,7,8,9,10,6 };
std::set the_set;
int count = 0;
for (unsigned i = 0; i < sizeof(array)/sizeof(*array); i++)
{
std::pair::iterator, bool> result =
the_set.insert(array[i]);
if (result.second)
count++;
}
printf("%d unique items in array.\n", count);
return 0;
}
compiled using g++ -std=c++98 -Os this produces what looks to me as
very inefficient code.
Particularly this loop in main():
40076d: 89 d8 mov%ebx,%eax
40076f: 4c 89 e7mov%r12,%rdi
400772: 48 8d 34 85 60 0a 40lea0x400a60(,%rax,4),%rsi
400779: 00
40077a: e8 b1 01 00 00 callq 400930 , std::allocator >::insert(int const&)>
40077f: 48 89 04 24 mov%rax,(%rsp)
400783: 89 54 24 08 mov%edx,0x8(%rsp)
400787: 48 89 44 24 40 mov%rax,0x40(%rsp)
40078c: 48 8b 44 24 08 mov0x8(%rsp),%rax
400791: 3c 01 cmp$0x1,%al
400793: 48 89 44 24 48 mov%rax,0x48(%rsp)
400798: 83 dd ffsbb$0x,%ebp
40079b: ff c3 inc%ebx
40079d: 83 fb 0bcmp$0xb,%ebx
4007a0: 75 cb jne40076d
And the uninlined set::insert():
00400930 , std::allocator
>::insert(int const&)>:
400930: 48 83 ec 48 sub$0x48,%rsp
400934: e8 5f ff ff ff callq 400898
, std::less,
std::allocator >::_M_insert_unique(int const&)>
400939: 89 54 24 18 mov%edx,0x18(%rsp)
40093d: 8a 54 24 18 mov0x18(%rsp),%dl
400941: 88 54 24 28 mov%dl,0x28(%rsp)
400945: 8b 54 24 28 mov0x28(%rsp),%edx
400949: 48 83 c4 48 add$0x48,%rsp
40094d: c3 retq
40094e: 90 nop
40094f: 90 nop
In the larger program, I got almost these exact results using
"-fprofile-use -O3", but since I have replicated it using -Os and
without PGO maybe it will be easier to debug/optimize.
That zero-result stack shuffling, and the unused stack frames are strange.
Am I reading the code wrong? Should I be using a different version of
the compiler? Is this a known bug?
Please advise.
Re: Discussion about merging Go frontend
On 29 Oct 2010, at 09:56, Dave Korn wrote: This implements an object file reader/writer which does everything required by LTO and gccgo. The ELF code works. I have not tested the Mach-O and COFF code at all beyond compiling it; I hope that somebody else can test those targets and fix them. I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be available. I tried with 166058 on ppc-darwin9 (my other machines are tied up right now) -flto fails on link with missing _main. e.g: Executing on host: /Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/xgcc -B/ Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/ c_lto_20081024_0.o - O0 -flto -m32 -o gcc-dg-lto-20081024-21(timeout = 60) Undefined symbols: "_main", referenced from: start in crt1.10.5.o -whopr ices with: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0, pfn=0x1d7ec , data=0xb19c, err=0xb198) at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469 469 memcpy (name, sechdr + sectname_offset, MACH_O_NAME_LEN); (gdb) bt #0 0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0, pfn=0x1d7ec , data=0xb19c, err=0xb198) at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469 #1 0x007f5dbc in objfile_find_sections (objfile=unavailable, due to optimizations>, pfn=unavailable, due to optimizations>, data=unavailable, due to optimizations>, err=unavailable, due to optimizations>) at /GCC/gcc-live-trunk/libiberty/ objfile.c:173 #2 0x0001dc60 in lto_obj_build_section_table (lto_file=temporarily unavailable, due to optimizations>) at /GCC/gcc-live-trunk/ gcc/lto/lto-objfile.c:270 #3 0x0001af80 in lto_read_all_file_options () at /GCC/gcc-live-trunk/ gcc/lto/lto.c:2052 #4 0x3960 in lto_post_options (pfilename=unavailable, due to optimizations>) at /GCC/gcc-live-trunk/gcc/lto/lto- lang.c:709 #5 0x004f0eec in toplev_main (argc=15, argv=Cannot access memory at address 0x1c ) at /GCC/gcc-live-trunk/gcc/toplev.c:1778 #6 0x1944 in start () if you need more analysis - ping me with what and I'll try and do sth -- or maybe Jack can help with a user on his machine. cheers, Iain
Re: Discussion about merging Go frontend
On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote: > On 29/10/2010 02:31, Ian Lance Taylor wrote: > > Dave Korn > > >> What would be even nicer would be if we could share the same code-reader > >> interface between lto and go (and the lto-plugin), thereby getting object > >> format independence equally everywhere for no extra cost. > > > > How about this? > > That looks excellent, thank you! > > > This implements an object file reader/writer which does everything > > required by LTO and gccgo. The ELF code works. I have not tested the > > Mach-O and COFF code at all beyond compiling it; I hope that somebody > > else can test those targets and fix them. > > I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be > available. > Dave, Doesn't the go compiler require functional split stack support? Mike Stump left me with the impression that split stack support would require additional linker support on darwin. Jack > > With this patch, libelf is no longer needed. > > > > I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO > > testsuite. > > > > This patch puts the code in libiberty, but it could equally well go in > > gcc. Anybody want to make an argument one way or another? > > Libiberty is better for sharing with lto-plugin, I think. I sent a patch > that commoned out some of the COFF-reader code into gcc/, but I only put it > there because it was a single header file with no associated object file. Now > there's actual code to be linked in, I think libiberty is a better choice than > lto-plugin trying to share .o files from the ../gcc/ objdir. > > > Does the general interface look OK? > > > > This patch requires approval from the LTO maintainers. > > Also, I have a patch outstanding to COFF-ize the lto-plugin(*), so if we can > get an early "OK in principle" I'll get cracking on respinning it to use this > new interface. > > cheers, > DaveK > -- > (*) - http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02176.html
Re: Discussion about merging Go frontend
On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote: > Dave Korn writes: > >> What would be even nicer would be if we could share the same code-reader >> interface between lto and go (and the lto-plugin), thereby getting object >> format independence equally everywhere for no extra cost. > > How about this? > > This implements an object file reader/writer which does everything > required by LTO and gccgo. The ELF code works. I have not tested the > Mach-O and COFF code at all beyond compiling it; I hope that somebody > else can test those targets and fix them. > > With this patch, libelf is no longer needed. > > I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO > testsuite. > > This patch puts the code in libiberty, but it could equally well go in > gcc. Anybody want to make an argument one way or another? > > Does the general interface look OK? > > This patch requires approval from the LTO maintainers. I don't need > approval for the libiberty changes (if the code stays in libiberty) but > of course I would appreciate it if somebody could look it over. I think > the configure and Makefile changes are sufficiently obvious given the > other changes as to not require approval. > > If this patch is accepted, then gccgo will not require elfcpp. Nice! The LTO changes are ok (I suppose you'll be around in helping people debug eventual problems). Richard. > Ian > > > include/ChangeLog: > > 2010-10-28 Ian Lance Taylor > > * objfile.h: New file. > > libiberty/ChangeLog: > > 2010-10-28 Ian Lance Taylor > > * objfile.c: New file. > * objfile-common.h: New file. > * objfile-elf.c: New file. > * objfile-mach-o.c: New file. > * objfile-coff.c: New file. > * configure.ac: Add AC_TYPE_SSIZE_T. > * Makefile.in: Rebuild dependencies. > (CFILES): Add objfile.c, objfile-coff, objfile-elf.c, > objfile-mach-o.c. > (REQUIRED_OFILES): Add corresponding object files. > * configure: Rebuild. > * config.in: Rebuild. > > gcc/ChangeLog: > > 2010-10-28 Ian Lance Taylor > > * configure.ac: Remove elf_getshdrstrndx test. Don't substitute > LTO_BINARY_READER or LTO_USE_LIBELF. Remove LIBELFLIBS and > LIBELFINC. Remove HAVE_libelf. > * gcc/config.gcc: Don't set lto_binary_reader. > * gcc/Makefile.in (LIBELFLIBS, LIBELFINC): Remove variables. > (LTO_BINARY_READER, LTO_USE_LIBELF): Remove variables. > (LIBS): Remove $(LIBELFLIBS). > (INCLUDES): Remove $(LIBELFINC). > * doc/install.texi (Prerequisites): Remove libelf paragraphs. > (Configuration): Mention --disable-lto. Remove --with-libelf > paragraph. > * configure: Rebuild. > * config.in: Rebuild. > > gcc/lto/ChangeLog: > > 2010-10-28 Ian Lance Taylor > > * lto-objfile.c: New file. > * lto-elf.c: Remove file. > * lto-macho.c: Remove file. > * lto-macho.h: Remove file. > * lto-coff.c: Remove file. > * lto-coff.h: Remove file. > * Make-lang.in (LTO_OBJS): Change lto/$(LTO_BINARY_READER).o to > lto/lto-objfile.o. > ($(LTO_EXE)): Remove $(LTO_USE_LIBELF) > (lto/lto-objfile.o): New target. > (lto/lto-elf.o, lto/lto-coff.o, lto/lto-macho.o): Remove targets. > > ./ChangeLog: > > 2010-10-28 Ian Lance Taylor > > * configure.ac: Don't set default_enable_lto. Remove libelf tests. > * configure: Rebuild. > > >
Re: Discussion about merging Go frontend
On 29/10/2010 14:31, Richard Guenther wrote: > On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote: >> This patch requires approval from the LTO maintainers. I don't need >> approval for the libiberty changes (if the code stays in libiberty) but >> of course I would appreciate it if somebody could look it over. I think >> the configure and Makefile changes are sufficiently obvious given the >> other changes as to not require approval. >> >> If this patch is accepted, then gccgo will not require elfcpp. > > Nice! > > The LTO changes are ok (I suppose you'll be around in helping people > debug eventual problems). I'll start work on porting the lto-plugin to use the new interface. It'll subsume my plugin-for-coff patch. cheers, DaveK
Re: Discussion about merging Go frontend
On 29/10/2010 14:18, Jack Howarth wrote: > On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote: >> On 29/10/2010 02:31, Ian Lance Taylor wrote: >>> Dave Korn >> What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. >>> How about this? >> That looks excellent, thank you! >> >>> This implements an object file reader/writer which does everything >>> required by LTO and gccgo. The ELF code works. I have not tested the >>> Mach-O and COFF code at all beyond compiling it; I hope that somebody >>> else can test those targets and fix them. >> I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be >> available. >> > > Dave, >Doesn't the go compiler require functional split stack support? Ian will have to answer that, I don't know. > Mike Stump > left me with the impression that split stack support would require additional > linker support on darwin. Well, this also affects LTO, since it refactors the object file support underlying that. As Iain has discovered... cheers, DaveK
Re: Discussion about merging Go frontend
Jack Howarth writes: >Doesn't the go compiler require functional split stack support? Mike Stump > left me with the impression that split stack support would require additional > linker support on darwin. The Go compiler can work without split stack support. The effect is that you are limited in the number of goroutines you can create, particularly on a 32-bit system. And you are also limited in the depth of recursion and size of local variables you can create. But you can write working Go programs. The objfile patch, however, is not really about Go, although gccgo will use it. It's really about LTO. If it works for LTO, it will work for gccgo. Ian
Re: define_split
roy rosen writes: > How are they split before register allocation or scheduling. We've > said that in any case only the combiner does the splitting. No, we haven't said that. Or, if we did, we made a mistake. The documentation I see says "There are two cases where you should specify how to split a pattern into multiple insns" and "[t]he insn combiner phase also splits putative insns." The first case, the case in which the combiner does not split insns, is the primary use case for define_split. I believe that we could remove the combiner's use of define_split with minimal or zero performance effect. > And another thing: gccint says that the define_split is used only if > there is no define_insn that matches - but you say now that 'people > just write the complex pattern using define_insn, and then write a > define_split (or a define_insn_and_split) which splits up the insn' so > I don't understand: if they write a define_insn then the pattern > matches and the split would not be used. I am confused... It is only when the combiner is splitting insns that the define_split is used only if there is no define_insn that matches. In the more typical case of splitting an insn, there is no such restriction. > Also, how do I build gccint from the current sources. Currently I just > use something I found in the internet. http://gcc.gnu.org/install/ Ian
Preprocessor (cpp) separate binary
Hi I am working on a tool for building all the possible variants of C code form the unpreprocessed file in order to perform an analysis on those files proving some sort of correctness. The idea is to make sure that any combination of preprocessor flags would produce a correct (in terms of some tool) C code. The first attempt was to build a grammar for unpreprocessed C code and then do all the rest. This project is here: http://cpplint.bsd.lv/ It is not finished and it have some design issues. It is a very complicated task to build a nice grammar for unpreprocessed C. It is very non-deterministic and you need to have quite some complicated tool to handle this. That is why now I want to use a gcc code-base for solving the same task. And the main problem for me at the moment is to build a cpp binary which would be able to handle options for preprocessor but which would not pull so many code from middleend and backend. In other words I want to have a separate binary for cpp. Anyone who is interested in the project or can help me with the separate binary issues pleas contact me. Thank you, Artem Shinkarov.
Re: Discussion about merging Go frontend
On Fri, Oct 29, 2010 at 06:49:51AM -0700, Ian Lance Taylor wrote: > Jack Howarth writes: > > >Doesn't the go compiler require functional split stack support? Mike > > Stump > > left me with the impression that split stack support would require > > additional > > linker support on darwin. > > The Go compiler can work without split stack support. The effect is > that you are limited in the number of goroutines you can create, > particularly on a 32-bit system. And you are also limited in the depth > of recursion and size of local variables you can create. But you can > write working Go programs. Ian, Is split stack support unique to the go compiler or might it eventually be leveraged in the other compilers as well? We could submit a radar for the addition of split stack support for the linker in Xcode 4.0 or later but it would helpful if the eventual usage was greater than just the go compiler. Jack > > The objfile patch, however, is not really about Go, although gccgo will > use it. It's really about LTO. If it works for LTO, it will work for > gccgo. > > Ian
Re: Discussion about merging Go frontend
On 10/28/2010 6:31 PM, Ian Lance Taylor wrote: > This patch requires approval from the LTO maintainers. I don't need > approval for the libiberty changes (if the code stays in libiberty) but > of course I would appreciate it if somebody could look it over. I think > the configure and Makefile changes are sufficiently obvious given the > other changes as to not require approval. This all looks good to me, and seems like a reasonable solution. I think libiberty is as good a place as any for the routines, FWIW. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: g++ produces crazy code for STL container
Zeev Tarantov writes: > I know this sounds like it might be better answered in gcc-help, but > if I am right this is a bug report. You can send bug reports to gcc-help also. For this case please file an optimization bug report at http://gcc.gnu.org/bugzilla with your test case. Indicate the exact instructions which seems useless to you. Thanks. Ian
Re: Discussion about merging Go frontend
Jack Howarth writes: >Is split stack support unique to the go compiler or might it eventually > be leveraged in the other compilers as well? We could submit a radar for > the addition of split stack support for the linker in Xcode 4.0 or later > but it would helpful if the eventual usage was greater than just the go > compiler. Split stack support is now in mainline and is available for any language via the -fsplit-stack option. The only thing unique to the Go frontend is that the Go frontend turns it on by default. Using it on Darwin will require some porting work of the assembly code in libgcc, which currently uses ELF pseudo-ops. Object files which are compiled with -fsplit-stack need to be marked in some way. What the linker needs to do is frob functions in object files compiled with -fsplit-stack which call functoins defined in object files compiled without -fsplit-stack. Ian
Re: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb:
> On 10/28/2010 03:10 PM, Georg Lay wrote:
>> Georg Lay schrieb:
>>
>>> This code is not nice.
>>>
>>> ;; d8 = d4 * d6
>>> ;; d8 = d2
>>> ;; d2 = d8
>>> ;; return d2
>>
>> this should be
>>
>> ;; d2 = d4 * d6
>> ;; d8 = d2
>> ;; d2 = d8
>> ;; return d2
>
> It seems to me that some of your peepholes should instead be implemented
> using constraints and multiple alternatives (for example the xor one),
> so that reload and register allocation can do a better job. However I
> can't tell without looking at the code.
As far as I understand the internals, peephole2 matches due to predicates and
condition, it does not care for constraints (except for optional match_scratch)
The xor reads as
;; "*andsi3" "*iorsi3" "*xorsi3"
(define_insn "*si3"
[(set (match_operand:SI 0 "register_operand" "=d,d,d,!d,d,d")
(tric_bitop:SI (match_operand:SI 1 "register_operand" "%0,d,d,d,d,d")
(match_operand:SI 2 "reg_or_s10_operand"
"d,0,d,d,Ku9,Kc9")))]
""
"@
..."
[(set_attr "opt" "*,*,speed,size,*,*")
(set_attr "pipe" "ip")])
The machine has two types of registers: "a" that are used to address memory and
can only do very basic kind of arithmetic, and "d" that can do arithmetic. The
xor above allows three destinct operands.
The xor in my original example gets generated here:
;; $2 is a mask of the form 00..111..000 that
;; cannot be handled by "*andsi3"
(define_insn_and_split "*and3_zeroes-2.insert.ic"
[(set (match_operand:SI 0 "register_operand" "=&d")
(and:SI (match_operand:SI 1 "register_operand" "%d")
(match_operand:SI 2 "const_int_operand" "n")))]
"TARGET_COMBINE_INSNS
&& ..."
"#"
"&& reload_completed"
[(set (match_dup 0)
(and:SI (match_dup 1)
(match_dup 3)))
(set (match_dup 0)
(xor:SI (match_dup 0)
(match_dup 1)))]
{
rtx lo, hi;
if (REGNO(operands[0]) == REGNO(operands[1]))
FAIL;
if (...)
{
/* We can load the constant in one instruction. This is better than
insert */
...
DONE;
}
operands[3] = GEN_INT (~OPVAL(2));
})
The condition will ensure that the mask (op2) is of the form indicated in the
comment.
Perhaps it is better to write this with a clobber operand instead of an
early-clobber. Maybe it's better to write it as a split1 that works prior to
reload instead of split2 that works after reload. I don't know. match_scratch
has the disadvantage that the input pattern will become a PARALLEL and is no
more a single_set. But let me explain why the pattern is there at all:
There are many cases where insn combine produces patterns that are close to
things that the machine do in one or maybe two instructions. In these situations
you want to say "hey combine, you are producing good stuff, but please go
further in this direction". That is the point where you want to do arithmetic on
RTL-level and transform one RTL construct into another or into a small sequence.
Note that I am a backend guy and the opportunities to introduce target specific
instructions are quite few: expand to do basics, and insn combine, split1
(before reload), split2 (after reload) for more fancy kind of instructions and
peephole (which I don't intend to use) and peephole2 to fix mess. So the
define_insn_and_split helps the combiner to combine more complex instructions
and the split won't be reached in many situations because the combiner stuffs
the AND in some complex insn that it wouldn't have found without the
define_insn_and_split (or without a define_insn).
Georg
Re: peephole2: dead regs not marked as dead
On 10/29/2010 05:08 PM, Georg Lay wrote: As far as I understand the internals, peephole2 matches due to predicates and condition, it does not care for constraints (except for optional match_scratch) Yes, I was referring as "using constraints in the define_insn". But you're dong that as far as I see. Maybe it's better to write it as a split1 that works prior to reload instead of split2 that works after reload. Yes, a split1 sounds much better. It will give much more freedom to reload and the register allocation to do exactly the liveness-based kind of optimization that you're doing with a peephole. I don't know. match_scratch has the disadvantage that the input pattern will become a PARALLEL and is no more a single_set. I don't understand why you mentioned match_scratch :) anyway note that a parallel of SET and CLOBBERs is a single_set. Paolo
Re: Preprocessor (cpp) separate binary
Artem Shinkarov writes: > That is why now I want to use a gcc code-base for solving the same > task. And the main problem for me at the moment is to build a cpp > binary which would be able to handle options for preprocessor but > which would not pull so many code from middleend and backend. In other > words I want to have a separate binary for cpp. Why? I concede that the fact that cpp invokes the whole compiler is a bit ugly and perhaps slightly inefficient. But it's not all that bad and it does work today. The goals of your project seem entirely separable from the goal of having a single cpp binary. Ian
Re: Preprocessor (cpp) separate binary
On Fri, Oct 29, 2010 at 4:21 PM, Ian Lance Taylor wrote: > Artem Shinkarov writes: > >> That is why now I want to use a gcc code-base for solving the same >> task. And the main problem for me at the moment is to build a cpp >> binary which would be able to handle options for preprocessor but >> which would not pull so many code from middleend and backend. In other >> words I want to have a separate binary for cpp. > > Why? > > I concede that the fact that cpp invokes the whole compiler is a bit > ugly and perhaps slightly inefficient. But it's not all that bad and it > does work today. The goals of your project seem entirely separable from > the goal of having a single cpp binary. Yes, you are right the goals are of course separable but my concern is the following. All that I want to implement is a different behaviour for handling conditional an macros. So basically all the modifications are on the side of cpplib. Now when I want to have an interface for that for just giving a file to the cpplib I end up with a 40 MB binary (instead of 2 MB) and the most of the code will never be used. Another thing is when I'll have a modified version of cpplib which is going to be interfaces with c_parser and c-typeck, ... I'll have to put the same files with small modifications in a single front-end directory. The code would be doubled and the synchronization will be broken. So this way seems very ugly to me. On the other hand, cpp by its nature does not have to do anything with the internals of C. I mean that preprocessor should not care what kid of code it preprocesses. So my idea is to create just a light version of cpp binary. I'm not saying that we need to replace an existing approach of preprocessing used in gcc (cpp is basically "gcc -E"). I'm just saying that it could be a nice thing to have. I am ready to do that in terms of my project, but I need some help because I don't know all the internal secrets and features. So I ask for help in the design of such a thing. Of course if it does not sound like an absolutely useless. > > Ian > Artem Shinkarov
Re: Preprocessor (cpp) separate binary
On Fri, 29 Oct 2010 16:45:43 +0100
Artem Shinkarov wrote:
>
> Yes, you are right the goals are of course separable but my concern is
> the following. All that I want to implement is a different behaviour
> for handling conditional an macros. So basically all the modifications
> are on the side of cpplib.
>
> Now when I want to have an interface for that for just giving a file
> to the cpplib I end up with a 40 MB binary (instead of 2 MB) and the
> most of the code will never be used.
>
A possible solution might be to use something else than GCC as a
preprocessor. For instance, ucpp http://code.google.com/p/ucpp/ claims
to be standard conforming, and is probably much smaller.
And I would tend to believe that hacking GCC to make its preprocessor a
separate & smaller thing is a big work, and might perhaps not easily
interest or motivate enough the rest of the GCC community.
Cheers.
--
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: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb: > On 10/29/2010 05:08 PM, Georg Lay wrote: >> As far as I understand the internals, peephole2 matches due to >> predicates and >> condition, it does not care for constraints (except for optional >> match_scratch) > > Yes, I was referring as "using constraints in the define_insn". But > you're dong that as far as I see. > >> Maybe it's better to write it as a split1 that works prior to >> reload instead of split2 that works after reload. > > Yes, a split1 sounds much better. It will give much more freedom to > reload and the register allocation to do exactly the liveness-based kind > of optimization that you're doing with a peephole. Ok, if I use the following the split is still after reload... (define_insn_and_split "" [(set (match_operand:SI 0 "register_operand" "=d") (and:SI (match_operand:SI 1 "register_operand" "d") (match_operand:SI 2 "const_int_operand" "n"))) (clobber (match_scratch:SI 3 "=&d"))] "..." "#" "&& reload_completed" [(set (match_dup 3) (and:SI (match_dup 1) (match_dup 4))) (set (match_dup 0) (xor:SI (match_dup 3) (match_dup 1)))] ...) And I do not know if it is wise to increase register pressure witch might lead to more spills. And if I try the pre-reload split (define_split [(set (match_operand:SI 0 "register_operand" "") (and:SI (match_operand:SI 1 "register_operand" "") (match_operand:SI 2 "const_int_operand" ""))) (clobber (match_operand:SI 3 "register_operand" ""))] "..." [(set (match_dup 3) (and:SI (match_dup 1) (match_dup 4))) (set (match_dup 0) (xor:SI (match_dup 3) (match_dup 1)))] the split does not occur and I get worse code. In fact there is no way to do pre-reload RTL-algebra in the BE. Even this simple case fails (I guess because there is no spare reg in the respective pass, combine or split1). The internals are not very helpful when you try to learn how RTL-transforms are best made in the BE. Would help much if gen_reg_rtx was allowed in these situations. If I use expand then combine won't see an AND and so I have no more the possibility to guide the combiner in the direction of complex patterns. Georg
Re: peephole2: dead regs not marked as dead
On 10/29/2010 06:18 PM, Georg Lay wrote: (define_split [(set (match_operand:SI 0 "register_operand" "") (and:SI (match_operand:SI 1 "register_operand" "") (match_operand:SI 2 "const_int_operand" ""))) (clobber (match_operand:SI 3 "register_operand" ""))] "..." [(set (match_dup 3) (and:SI (match_dup 1) (match_dup 4))) (set (match_dup 0) (xor:SI (match_dup 3) (match_dup 1)))] Again, it's not really my field but I think this should be written as (define_split [(set (match_operand:SI 0 "register_operand" "") (and:SI (match_operand:SI 1 "register_operand" "") (match_operand:SI 2 "const_int_operand" ""))) (clobber (match_scratch:SI 3 ""))] "" [(set (match_dup 3) (and:SI (match_dup 1) (match_dup 4))) (set (match_dup 0) (xor:SI (match_dup 3) (match_dup 1)))] and the define_insn should also use match_scratch. I'm looking at config/i386/i386.md, pattern fix_trunc_i387_fisttp_with_temp and the two following splits. If you do it pre-reload, register allocation should not have any problem allocating operands 0 and 3 to the same register. It sounds to me like you're doing your own register allocation using peepholes. :) Paolo
RE: Bug in expand_builtin_setjmp_receiver ?
Hi Fred, > If you have access to a lm32 toolchain, can you test if gcc.c- > torture/execute/built-in-setjmp.c passes at different optimization levels? For a SVN snapshot from yesterday, patched so it fixes the problem Nathan mentioned: FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O2 FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O3 -g FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -Os FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O2 -flto FAIL: gcc.c-torture/execute/built-in-setjmp.c execution, -O2 -fwhopr Cheers, Jon
GCC Summit 2010 papers and presentations
I have collected most papers and presentations for this year's GCC summit at http://gcc.gnu.org/wiki/summit2010 Authors: please check and make sure that I uploaded the right content. If you find a problem and can edit the wiki, please fix it yourself. If not, contact me and I will fix it for you. It is still missing some papers and slides. Thanks. Diego.
Re: Preprocessor (cpp) separate binary
Artem Shinkarov writes: > So my idea is to create just a light version of cpp binary. I'm not > saying that we need to replace an existing approach of preprocessing > used in gcc (cpp is basically "gcc -E"). I'm just saying that it could > be a nice thing to have. > > I am ready to do that in terms of my project, but I need some help > because I don't know all the internal secrets and features. So I ask > for help in the design of such a thing. Of course if it does not sound > like an absolutely useless. I'm not sure this is useful for the gcc project. However, I'm certainly in favor of documenting internal API's in gcc, and if you can use that to build the tool you want, then that would be fine. There are no internal "secrets," of course. The libcpp library API is defined in libcpp/include/cpplib.h. Specifically, you must set some fields in a struct cpp_callbacks and you must call cpp_push_include to set the header file search path. You should probably start by looking at the file gcc/c-family/c-ppoutput.c (just gcc/c-ppoutput.c in older releases) to see what gcc does for -E. You're going to have to do some digging to make this work. Ian
TARGET_VALID_POINTER_MODE unused?
I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that define it... but I don't see any code that uses it. Did I miss it? paul
Re: TARGET_VALID_POINTER_MODE unused?
On Fri, Oct 29, 2010 at 2:28 PM, Paul Koning wrote:
> I see documentation for TARGET_VALID_POINTER_MODE, and I see ports that
> define it... but I don't see any code that uses it.
Ok, there are two issues it seems. First it is used in target.def:
/* True if MODE is valid for a pointer in __attribute__((mode("MODE"))). */
DEFHOOK
(valid_pointer_mode,
"",
bool, (enum machine_mode mode),
default_valid_pointer_mode)
But the other issue is that the default
default_addr_space_pointer_mode does not use it which means it is
unused really. I think we should only have one or the other hook
really.
-- Pinski
gcc's(4.4.3) math lib :power
dear gcc programers:
I tried to use math lib's power by the following simple code
(actually I copy from
http://www.java2s.com/Code/C/Math/Howtousepow.htm
that site show this code should run, but I get compiler error about not define
pow, please help, Eric, in 4.4.3
-
e...@eric-laptop:~$ cat try.c
#include
#include
int main () {
double x = 10.0, y = 0.0;
do {
printf("%f\n", pow(x, y));
y++;
} while (y<11.0);
return(0);
}
e...@eric-laptop:~$ gcc try.c
/tmp/ccQIeWnf.o: In function `main':
try.c:(.text+0x29): undefined reference to `pow'
collect2: ld returned 1 exit status
---
Re: gcc's(4.4.3) math lib :power
> that site show this code should run, but I get compiler error Actually you get a *linker* (ie, ld) error. Try adding -lm to the command line. Paolo Ps: in the future please prefer gcc-help...
Re: Discussion about merging Go frontend
Paolo Bonzini writes: > On 10/24/2010 07:40 AM, Ian Lance Taylor wrote: >> configure.ac >>Add libgo. If building Go, build C++ as a boot language. > > Can you generalize this using something in gcc/go/config-lang.in? I have now done this on the gccgo branch. If language X's config-lang.in sets the shell variable lang_requires_boot_language, then if X is enabled all those languages are built during stage 1. Ian
Re: Discussion about merging Go frontend
On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote: > Paolo Bonzini writes: > >> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote: >>> configure.ac >>> Add libgo. If building Go, build C++ as a boot language. >> >> Can you generalize this using something in gcc/go/config-lang.in? > > I have now done this on the gccgo branch. If language X's > config-lang.in sets the shell variable lang_requires_boot_language, then > if X is enabled all those languages are built during stage 1. > Don't we have boot_language for this purpose? -- H.J.
Re: Discussion about merging Go frontend
"H.J. Lu" writes: > On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote: >> Paolo Bonzini writes: >> >>> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote: configure.ac Add libgo. If building Go, build C++ as a boot language. >>> >>> Can you generalize this using something in gcc/go/config-lang.in? >> >> I have now done this on the gccgo branch. If language X's >> config-lang.in sets the shell variable lang_requires_boot_language, then >> if X is enabled all those languages are built during stage 1. >> > > Don't we have boot_language for this purpose? No, boot_language serves a different purpose. It says that the language itself should be built during stage 1. What I need for Go is to say that C++ should be built during stage 1. That is, boot_language is a yes or no value. I have added lang_requires_boot_language, which takes a list of languages. It is similar to lang_requires, except that it specifically builds the specified languages during stage 1. Ian
Re: Help with reloading FP + offset addressing mode
Quoting Mohamed Shafi : On 29 October 2010 00:06, Joern Rennecke wrote: Quoting Mohamed Shafi : Hi, I am doing a port in GCC 4.5.1. For the port 1. there is only (reg + offset) addressing mode only when reg is SP. Other base registers are not allowed 2. FP cannot be used as a base register. (FP based addressing is done by copying it into a base register) In order to take advantage of FP elimination (this will create SP + offset addressing), what i did the following 1. Created a new register class (address registers + FP) and used this new class as the BASE_REG_CLASS Stop right there. You need to distinguish between FRAME_POINTER_REGNUM and HARD_FRAME_POINTER_REGNUM. From the description given in the internals, i am not able to understand why you suggested this. Could you please explain this? In order to trigger reloading of the address, you have to have a register elimination, even if the stack pointer is not a suitable destinatination for the elimination. Also, if you want to reload do the work for you, you must not lie to it about the addressing capabilities of an actual hard register. Hence, you need separate hard and soft frame pointers. If you have them, but conflate them when you describe what you are doing in your port, you are not only likely to confuse the listener/reader, but also your documentation, your code, and ultimately yourself.
Re: Discussion about merging Go frontend
> +extern objfile_read * > +objfile_open_read (int descriptor, off_t offset, const char *segment_name, > +const char **errmsg, int *err); ... > +extern objfile_write * > +objfile_start_write (objfile_attributes *ATTRS, const char *segment_name, > + const char **errmsg, int *err); Mismatch in naming conventions? I like the use of "release" to clearly indicate non-closure of the FD. > + shdr_size = (cl == ELFCLASS32 > +? sizeof (Elf32_External_Shdr) > +: sizeof (Elf64_External_Shdr)); > + memset (buf, 0, shdr_size); Constant size memset is easier to optimize. You might as well zero all of BUF, even if we're not going to use it all. The slop between 32 and 64 is minimal. > + if (!objfile_internal_read (objfile->descriptor, > + objfile->offset + eor->shoff + shdr_size, > + shdrs, > + shdr_size * (shnum - 1), > + &errmsg, err)) Do we really want to keep re-reading section data for every section lookup we do? Can't we do this in objfile_open_read? > + set_32 (hdr + offsetof (struct external_scnhdr, s_flags), > + (STYP_DATA | IMAGE_SCN_ALIGN_1BYTES | IMAGE_SCN_MEM_DISCARDABLE > +| IMAGE_SCN_MEM_SHARED | IMAGE_SCN_MEM_READ)); You're not recording alignment in the coff object file? IMAGE_SCN_ALIGN_BYTES, 1 <= N <= 8192, are all defined with a simple function in that nibble. r~
Re: Discussion about merging Go frontend
On Fri, Oct 29, 2010 at 4:39 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote: >>> Paolo Bonzini writes: >>> On 10/24/2010 07:40 AM, Ian Lance Taylor wrote: > configure.ac > Add libgo. If building Go, build C++ as a boot language. Can you generalize this using something in gcc/go/config-lang.in? >>> >>> I have now done this on the gccgo branch. If language X's >>> config-lang.in sets the shell variable lang_requires_boot_language, then >>> if X is enabled all those languages are built during stage 1. >>> >> >> Don't we have boot_language for this purpose? > > No, boot_language serves a different purpose. It says that the language > itself should be built during stage 1. What I need for Go is to say > that C++ should be built during stage 1. That is, boot_language is a > yes or no value. I have added lang_requires_boot_language, which takes Will put if [ Go is enabled ]; then boot_language=yes fi in cp/config-lang.in work? -- H.J.
