Re: Committed Go frontend
Ian Lance Taylor writes: > As I just mentioned on the gcc-patches mailing list, I have just > committed the Go frontend to mainline. What's the name of the resulting compiler binary? "ggo"? -Miles -- Opposition, n. In politics the party that prevents the Goverment from running amok by hamstringing it.
Re: Committed Go frontend
Joern Rennecke writes: > Quoting Andrew Pinski : > >> On Thu, Dec 2, 2010 at 8:41 PM, Ian Lance Taylor wrote: >>> The Go language is not built by default, so this should not have a >>> significant effect on most developers. >> >> Hmm, but it looks like it is currently. > > Indeed, as of r167408, --enable-languages=all includes go. Well, yeah. Isn't that exactly what should happen? When I said it wasn't built by default, I meant that it wasn't built if you don't use a --enable-languages option. Ian
Re: RFA: patch to prohibit IRA undoing sched1 [was IRA undoing sched1]
On 12/02/10 15:17, Vladimir Makarov wrote: On 12/01/2010 02:14 PM, Paul Koning wrote: On Nov 29, 2010, at 9:51 PM, Vladimir Makarov wrote: On 11/29/2010 08:52 PM, Paul Koning wrote: I'm doing some experiments to get to know GCC better, and something is puzzling me. I have defined an md file with DFA and costs describing the fact that loads take a while (as do stores). Also, there is no memory to memory move, only memory to/from register. Test program is basically a=b; c=d; e=f; g=h; Sched1, as expected, turns this into four loads followed by four stores, exploiting the pipeline. Then IRA kicks in. It shuffles the insns back into load/store, load/store pairs, essentially the source code order. It looks like it's doing that to reduce the number of registers used. Fair enough, but this makes the code less efficient. I don't see a way to tell IRA not to do this. Most probably that happens because of ira.c::update_equiv_regs. This function was inherited from the old register allocator. The major goal of the function is to find equivalent memory/constants/invariants for pseudos which can be used by reload pass. Pseudo equivalence also affects live range splitting decision in IRA. Update_equiv_regs can also move insns initiating pseudo equivalences close to the pseudo usage. You could try to prevent this and to see what happens. IMO preventing such insn moving will do more harm on performance on SPEC benchmarks for x86/x86-64 processors. As it happens, there's a secondary reload involved: the loads are into one set of registers but the stores from another, so a register to register move is added in by reload. Does that explain the behavior? I tried changing the cover_classes, but that doesn't make a difference. It is hard to say without the dump file. If everything is correctly defined, it should not happen. I extended the test code a little, and fed it to a mips64el-elf targeted gcc. It showed the same pattern in one of the two functions but not the other. The test code is test8.c (attached). What I see in the assembly output (test8.s, also attached) is that foo() has a load then store then load then store pattern, which contradicts what sched1 constructed and doesn't take advantage of the pipeline. However, bar() does use the pipeline. I don't know what's different between these two. Do you want some dump file (which ones)? Or you could just reproduce this with the current gcc, it's a standard target build. The compile was -O2 -mtune=mips64r2 -mabi=n32. As I guessed the problem is in update_reg_equiv transformation trying to move initialization insn close to its single use to decrease the register pressure. A lot of people already complaint about undoing scheduling by this function. The following patch solves the problem when you use -fsched-pressure. I would not like to do that for regular (not register pressure-sensitive) insn scheduling for obvious reasons. I think most RISC targets (including MIPS ones) should make -fsched-pressure by default. 2010-12-02 Vladimir Makarov * ira.c (update_equiv_regs): Prohibit move insns if pressure-sensitive scheduling was done. Jeff, sorry for bothering you. Is it ok to commit the patch to the trunk? It seems fairly reasonable to me, at least in the short term. ISTM that longer term we'd want to do these transformations when we're unable to allocate the affected pseudos to hard regs. ie, leave the schedule alone unless it results in an inability to get a reasonable allocation jeff
Re: Committed Go frontend
I notice two files in the front end have '#include "ansidecl.h"'. ansidecl.h is automatically included from config.h so it is not conventional for files in GCC to include it directly. -- Joseph S. Myers jos...@codesourcery.com
Re: Committed Go frontend
Hi, On Fri, 3 Dec 2010, Ian Lance Taylor wrote: > Joern Rennecke writes: > > > Quoting Andrew Pinski : > > > >> On Thu, Dec 2, 2010 at 8:41 PM, Ian Lance Taylor wrote: > >>> The Go language is not built by default, so this should not have a > >>> significant effect on most developers. > >> > >> Hmm, but it looks like it is currently. > > > > Indeed, as of r167408, --enable-languages=all includes go. > > Well, yeah. Isn't that exactly what should happen? The precedent would be Ada. It is not included in =all, you explicitely have to enable it via e.g. =all,ada . I would have thought Go to behave similarly. In particular =all selects all languages that leave build_by_default set to yes in their config-lang.in ... > When I said it wasn't built by default, I meant that it wasn't built if > you don't use a --enable-languages option. Ciao, Michael.
Re: Committed Go frontend
I don't see a ChangeLog file in the gcc/go directory - I take it one will be created for all future changes to that directory outside of the gofrontend subdirectory? -- Joseph S. Myers jos...@codesourcery.com
Re: Committed Go frontend
Miles Bader writes: > Ian Lance Taylor writes: >> As I just mentioned on the gcc-patches mailing list, I have just >> committed the Go frontend to mainline. > > What's the name of the resulting compiler binary? "ggo"? gccgo. Ian
Re: libstdc++ gets configure error in cross builds
On Dec 2, 2010, at 4:06 PM, H.J. Lu wrote: > On Thu, Dec 2, 2010 at 1:01 PM, Paul Koning wrote: >> >> On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: >> >>> On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote: On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: > Paul Koning writes: > >> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: >> >>> Paul Koning writes: >>> I'm trying to do a cross-build of gcc 4.5.1. It works fine until I get to libstdc++v3, where configure blows up with a message saying "Link tests are not allowed after GCC_NO_EXECUTABLES". This happens on the "checking for shl_load" step (line 11221 in configure). I looked at configure.ac to see if there were any clues. I can't tell which line in configure.ac produces the offending line in configure (not enough autoconf skills). In an earlier gcc (3.3.3) there was a similar issue, and in that case I worked around it by removing "GLIBCPP_CHECK_COMPILER_VERSION" from the configure.in file. But that line doesn't exist in configure.ac and attempts to find something analogous didn't get me anywhere. >>> >>> GCC_NO_EXECUTABLES, in config/no-executables.m4, redefines >>> AC_LINK_IFELSE to produce that error message. >> >> Thanks. But why does the released configure fail like this? Any idea >> how to fix this bug? > > You need to tell us precisely what you tried to do and precisely what > happened. > > The TARGET/libstdc++-v3/config.log file may contain a clue. It's configured --target=mips64el-netbsdelf --enable-languages=c,c++, on an i686-pc-linux-gnu host. >>> >>> Can you try sysroot with full mips64el-netbsdelf C library and header >>> files? >> >> I have newlib and a full set of headers. >> > > Please DO use sysroot. That doesn't help. No real surprise; --with-sysroot doesn't change the fact that I'm building a cross-compiler, and that fact is what disables link tests. So the thing that appears to be needed is to avoid the link tests. The two patches I mentioned cure this issue and seem to make sense; I'll propose them. paul
Re: Committed Go frontend
"Joseph S. Myers" writes: > I don't see a ChangeLog file in the gcc/go directory - I take it one will > be created for all future changes to that directory outside of the > gofrontend subdirectory? Yes, and in fact already done as of a few minutes ago. Ian
Re: Committed Go frontend
Michael Matz writes: >> > Indeed, as of r167408, --enable-languages=all includes go. >> >> Well, yeah. Isn't that exactly what should happen? > > The precedent would be Ada. It is not included in =all, you explicitely > have to enable it via e.g. =all,ada . I would have thought Go to behave > similarly. In particular =all selects all languages that leave > build_by_default set to yes in their config-lang.in ... Yeah, I messed up. Sorry about that. Should be fixed now. Ian
Re: libstdc++ gets configure error in cross builds
On Fri, Dec 3, 2010 at 8:10 AM, Paul Koning wrote: > > On Dec 2, 2010, at 4:06 PM, H.J. Lu wrote: > >> On Thu, Dec 2, 2010 at 1:01 PM, Paul Koning wrote: >>> >>> On Dec 2, 2010, at 3:55 PM, H.J. Lu wrote: >>> On Thu, Dec 2, 2010 at 12:42 PM, Paul Koning wrote: > > On Dec 2, 2010, at 3:05 PM, Ian Lance Taylor wrote: > >> Paul Koning writes: >> >>> On Dec 2, 2010, at 2:55 PM, Ian Lance Taylor wrote: >>> Paul Koning writes: > I'm trying to do a cross-build of gcc 4.5.1. It works fine until I > get to libstdc++v3, where configure blows up with a message saying > "Link tests are not allowed after GCC_NO_EXECUTABLES". This happens > on the "checking for shl_load" step (line 11221 in configure). > > I looked at configure.ac to see if there were any clues. I can't tell > which line in configure.ac produces the offending line in configure > (not enough autoconf skills). In an earlier gcc (3.3.3) there was a > similar issue, and in that case I worked around it by removing > "GLIBCPP_CHECK_COMPILER_VERSION" from the configure.in file. But that > line doesn't exist in configure.ac and attempts to find something > analogous didn't get me anywhere. GCC_NO_EXECUTABLES, in config/no-executables.m4, redefines AC_LINK_IFELSE to produce that error message. >>> >>> Thanks. But why does the released configure fail like this? Any idea >>> how to fix this bug? >> >> You need to tell us precisely what you tried to do and precisely what >> happened. >> >> The TARGET/libstdc++-v3/config.log file may contain a clue. > > It's configured --target=mips64el-netbsdelf --enable-languages=c,c++, on > an i686-pc-linux-gnu host. > Can you try sysroot with full mips64el-netbsdelf C library and header files? >>> >>> I have newlib and a full set of headers. >>> >> >> Please DO use sysroot. > > That doesn't help. > > No real surprise; --with-sysroot doesn't change the fact that I'm building a > cross-compiler, and that fact is what disables link tests. So the thing that > appears to be needed is to avoid the link tests. > Link test should work with a fully populated sysroot, Build a complete cross toolchain, gcc + binutils + libc, is a different story. H.J.
Re: operator new[] overflow (PR 19351)
On Thu, Dec 02, 2010 at 02:47:30PM -0800, Gabriel Dos Reis wrote: > On Thu, Dec 2, 2010 at 2:20 PM, Joe Buck wrote: > > On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote: > >> * Chris Lattner: > >> > >> > On overflow it just forces the size passed in to operator new to > >> > -1ULL, which throws bad_alloc. > >> > >> This is also what my patch tries to implement. > > > > Yes, but Chris's code just checks the overflow of the multiply. Your > > patch achieves the same result in a more complex way, by > > computing the largest non-overflowing value of n in > > > > new T[n]; > > > > and comparing n against that. Even though max_size_t/sizeof T is a > > compile-time constant, this is still more expensive. > > I would expect max_size_t/sizeof(T) to be actually an integer > constant that n is compared against. I would be surprised > if that one-time comparison is noticeable in real applications that > new an array of objects. It's wasted code if the multiply instruction detects the overflow. It's true that the cost is small (maybe just one extra instruction and the same number of tests, maybe one more on architectures where you have to load a large constant), but it is slightly worse code than what Chris Lattner showed. Still, it's certainly an improvement on the current situation and the cost is negligible compared to the call to the allocator. Since it's a security issue, some form of the patch should go in.
Re: libstdc++ gets configure error in cross builds
Paul Koning writes:
I'm trying to do a cross-build of gcc 4.5.1.
It's configured --target=mips64el-netbsdelf --enable-languages=c,c++, on an
i686-pc-linux-gnu host.
Can you try sysroot with full mips64el-netbsdelf C library and header
files?
The NetBSD archive maybe haven't them... The stuff for embedde boards :
http://ftp.netbsd.org/pub/NetBSD/NetBSD-5.1/evbmips-mipsel/binary/sets/
had only a 32-bit sysroot but maybe some MIPS system port has the
64-bit ones.
I have newlib and a full set of headers.
Why you think these being suitable for NetBSD/mips64el ?
Please DO use sysroot.
That doesn't help.
So if you will unpack the suitable 'base.tgz' and 'comp.tgz' into
a sysroot and point them using '--with-sysroot=', the build
wouldn't succeed?
I haven't time to check this just now... BUT what I saw in
'gcc-4.5.1/gcc/config.gcc' was that the template was :
mips*-*-netbsd*)# NetBSD/mips, either endian.
target_cpu_default="MASK_ABICALLS"
tm_file="elfos.h ${tm_file} mips/elf.h netbsd.h netbsd-elf.h
mips/netbsd.h"
;;
so it doesn't care about your 'mips64' at all :( The GCC being
produced is a 32-bit target one and so the evbmips-mipsel stuff
would be suitable for the default...
Problem with memory alignment for 64 byte moves
Hello everyone. I'm porting gcc to a new architecture and I'm allowing use of movdi instructions as the processor allows 8 byte loads. The processor however requires 8 byte loads and stores to be naturally aligned, yet gcc seems to be emitting loads and stores that are 4 byte aligned. How can I make sure that gcc will only emit 8 byte loads and stores if it knows the address, which can be in a register, is 8 byte aligned?
Re: Update LTO plugin interface
> For the crtend files we could add a linker option that makes them > known as endcaps, and the linker could make sure they get laid out > last: > > ld ... -lc -lgcc ... --endcap crtend.o crtn.o > > That puts the special knowledge about those files back in the gcc driver. I should have remembered that I already dealt with this problem long ago -- gold defers the layout of all real objects that follow the first claimed IR file until after the replacement files have been laid out. With respect to physical layout of the sections, this effectively makes the link order equivalent to putting the replacement files in the place of the first IR file. No "endcap" option is necessary. -cary
Re: Update LTO plugin interface
>>> Another way to do this would be to put a marker in the command line >>> that identifies where those libraries begin, and the linker could just >>> go back and rescan those libraries if needed, before the final layout >>> of the endcaps. >> >> I like that idea in general, but the difficulty is knowing where to put >> the marker. E.g., the user is going to specify -lm, and we are going to >> need to rescan it. If the user writes -lm -lmylib1 -lmylib2 we want to >> rescan -lm but we don't really need to rescan mylib1 and mylib2. > > All those complexities make 2 stage linking more attractive. I > think I can implement it in GNU linker with the current plugin API. > > Linker just needs to remember the command line options, including > > --start-group/--end-group > -as-needed/--no-as-needed > --copy-dt-needed-entries/--no-copy-dt-needed-entries > > in stage 1. > > In stage 2, it will place LTO trans files before the first IR file > claimed by plugin and process the command line options. > > --whole-archive may need some special handling. Archives > after --whole-archive will be ignored in stage 2. It seems to me that we just need to add a few more libraries as pass-through libraries, being careful to add a pass-through option only for libraries that are already on the command line. How does that add up to "all those complexities"? With what you've written here, you've just added to the complexity of your proposed solution, which makes it a much bigger change -- especially since what you're proposing will require changes in both linkers. Adding pass-through options is a gcc driver change only. The pass-through option may be seen as a hack, but I don't think it's that big of a hack, and it does work. I don't see it as fundamentally different from adding an option to mark runtime support libraries -- the difference is really just syntax. In the long term, I'd prefer to see improvements more along the lines of what I've suggested earlier in this thread -- define a set of runtime support routines that the backend can generate calls to, and make those known to the linker so that they can be located during the first pass. That's the best way to ensure that we have a complete picture of the whole program for the optimizer. For now, I think it's sufficient to fix the driver to add the necessary pass-through options, and maybe gnu ld needs to be fixed to handle the crtend files correctly. We also should address Jan's concerns with COMDAT. -cary
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote: Another way to do this would be to put a marker in the command line that identifies where those libraries begin, and the linker could just go back and rescan those libraries if needed, before the final layout of the endcaps. >>> >>> I like that idea in general, but the difficulty is knowing where to put >>> the marker. E.g., the user is going to specify -lm, and we are going to >>> need to rescan it. If the user writes -lm -lmylib1 -lmylib2 we want to >>> rescan -lm but we don't really need to rescan mylib1 and mylib2. >> >> All those complexities make 2 stage linking more attractive. I >> think I can implement it in GNU linker with the current plugin API. >> >> Linker just needs to remember the command line options, including >> >> --start-group/--end-group >> -as-needed/--no-as-needed >> --copy-dt-needed-entries/--no-copy-dt-needed-entries >> >> in stage 1. >> >> In stage 2, it will place LTO trans files before the first IR file >> claimed by plugin and process the command line options. >> >> --whole-archive may need some special handling. Archives >> after --whole-archive will be ignored in stage 2. > > It seems to me that we just need to add a few more libraries as > pass-through libraries, being careful to add a pass-through option > only for libraries that are already on the command line. How does that > add up to "all those complexities"? > > With what you've written here, you've just added to the complexity of > your proposed solution, which makes it a much bigger change -- > especially since what you're proposing will require changes in both > linkers. Adding pass-through options is a gcc driver change only. > I will implement 2 stage linking in GNU linker with the current plugin API. The change shouldn't be too big. pass-through isn't needed. If we keep it in GCC driver, my linker will simply ignore it. One benefit is everything will just work, with or without LTO. -- H.J.
Re: Problem with memory alignment for 64 byte moves
Neil Hickey writes: > I'm porting gcc to a new architecture and I'm allowing use of movdi > instructions as the processor allows 8 byte loads. The processor > however requires 8 byte loads and stores to be naturally aligned, yet > gcc seems to be emitting loads and stores that are 4 byte aligned. How > can I make sure that gcc will only emit 8 byte loads and stores if it > knows the address, which can be in a register, is 8 byte aligned? Define STRICT_ALIGNMENT to 1. Make sure that BIGGEST_ALIGNMENT, BIGGEST_FIELD_ALIGNMENT, MAX_STACK_ALIGNMENT, DATA_ALIGNMENT, etc. are correct. Ian
Re: vector extension bug?
On 11/29/2010 03:25 PM, Ian Lance Taylor wrote: > Basically, the 64-bit calling convention support assumes that the SSE2 > instructions are always available, and silently fails when -mno-sse2 is > used. I don't really have an opinion as to whether the compiler needs > to support this case correctly, but I think that clearly it must not > silently fail. I believe it should non-silently fail to compile this. I really can't imagine a viable reason to introduce a soft-fp calling convention for the 64-bit compiler. If David really wants to continue with this project, he should be working with the 32-bit compiler, since (1) 32-bit cpus may legitimately not have SSE registers, and (2) it already has a calling convention that can handle this. r~
config/svr4.h
The configuration header config/svr4.h is used 74 times in config.gcc (plus one reference in a comment). This header is nominally "Operating system specific defines to be used when targeting GCC for some generic System V Release 4 system". GCC no longer supports any generic System V Release 4 systems (various generic such targets were obsoleted in 4.3). Instead, this header is used for various configurations with nothing much in common including bare-metal systems, GNU/Linux, uClinux, RTEMS, HP-UX, VxWork, NetBSD, OpenBSD, NetWare, QNX and TPF - but for many of these, only for a subset of the supported architectures. I don't believe there is any common essence of SVR4-ness among currently supported targets such that it makes sense to have a common header. Figuring out what options in specs should be added to .opt file for what targets also requires going through all 74 cases to find which specs in this header are overridden when (any serious hookization of SIZE_TYPE, PTRDIFF_TYPE and WCHAR_TYPE would also require figuring out just when the definitions in this header are relevant). Thus, I propose to remove this header, moving parts of it that are actually relevant and used for individual targets into more appropriate headers for those targets. For the target macros AS_NEEDS_DASH_FOR_PIPED_INPUT, MD_EXEC_PREFIX, MD_STARTFILE_PREFIX, TARGET_POSIX_IO I propose to do this on a per-macro basis (taking MD_*_PREFIX together), removing macro definitions from this header and putting them in better places for the targets that need them. For the other macros I propose to go through the targets one by one, and for each target put the required macros in another header and stop that target using svr4.h. svr3.h in principle has the same issue (no "generic System V Release 3 system" support in GCC), but as (a) it defines no specs and (b) it's only used by one target (mcore-*-pe*) it doesn't really cause problems in practice. Thus I don't currently plan to do anything with it. (I am not expecting any comments on this plan; this message is simply to avoid repeating what's wrong with svr4.h and what I am doing about it in every individual patch submission.) -- Joseph S. Myers jos...@codesourcery.com
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 11:16 AM, H.J. Lu wrote: > On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote: > Another way to do this would be to put a marker in the command line > that identifies where those libraries begin, and the linker could just > go back and rescan those libraries if needed, before the final layout > of the endcaps. I like that idea in general, but the difficulty is knowing where to put the marker. E.g., the user is going to specify -lm, and we are going to need to rescan it. If the user writes -lm -lmylib1 -lmylib2 we want to rescan -lm but we don't really need to rescan mylib1 and mylib2. >>> >>> All those complexities make 2 stage linking more attractive. I >>> think I can implement it in GNU linker with the current plugin API. >>> >>> Linker just needs to remember the command line options, including >>> >>> --start-group/--end-group >>> -as-needed/--no-as-needed >>> --copy-dt-needed-entries/--no-copy-dt-needed-entries >>> >>> in stage 1. >>> >>> In stage 2, it will place LTO trans files before the first IR file >>> claimed by plugin and process the command line options. >>> >>> --whole-archive may need some special handling. Archives >>> after --whole-archive will be ignored in stage 2. >> >> It seems to me that we just need to add a few more libraries as >> pass-through libraries, being careful to add a pass-through option >> only for libraries that are already on the command line. How does that >> add up to "all those complexities"? >> >> With what you've written here, you've just added to the complexity of >> your proposed solution, which makes it a much bigger change -- >> especially since what you're proposing will require changes in both >> linkers. Adding pass-through options is a gcc driver change only. >> > > I will implement 2 stage linking in GNU linker with the current plugin API. > The change shouldn't be too big. pass-through isn't needed. If we > keep it in GCC driver, my linker will simply ignore it. > > One benefit is everything will just work, with or without LTO. > I checked the first patch into hjl/lto branch at http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary Now I can collect stage 2 command line. -- H.J.
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 4:49 PM, H.J. Lu wrote: > On Fri, Dec 3, 2010 at 11:16 AM, H.J. Lu wrote: >> On Fri, Dec 3, 2010 at 11:10 AM, Cary Coutant wrote: >> Another way to do this would be to put a marker in the command line >> that identifies where those libraries begin, and the linker could just >> go back and rescan those libraries if needed, before the final layout >> of the endcaps. > > I like that idea in general, but the difficulty is knowing where to put > the marker. E.g., the user is going to specify -lm, and we are going to > need to rescan it. If the user writes -lm -lmylib1 -lmylib2 we want to > rescan -lm but we don't really need to rescan mylib1 and mylib2. All those complexities make 2 stage linking more attractive. I think I can implement it in GNU linker with the current plugin API. Linker just needs to remember the command line options, including --start-group/--end-group -as-needed/--no-as-needed --copy-dt-needed-entries/--no-copy-dt-needed-entries in stage 1. In stage 2, it will place LTO trans files before the first IR file claimed by plugin and process the command line options. --whole-archive may need some special handling. Archives after --whole-archive will be ignored in stage 2. >>> >>> It seems to me that we just need to add a few more libraries as >>> pass-through libraries, being careful to add a pass-through option >>> only for libraries that are already on the command line. How does that >>> add up to "all those complexities"? >>> >>> With what you've written here, you've just added to the complexity of >>> your proposed solution, which makes it a much bigger change -- >>> especially since what you're proposing will require changes in both >>> linkers. Adding pass-through options is a gcc driver change only. >>> >> >> I will implement 2 stage linking in GNU linker with the current plugin API. >> The change shouldn't be too big. pass-through isn't needed. If we >> keep it in GCC driver, my linker will simply ignore it. >> >> One benefit is everything will just work, with or without LTO. >> > > I checked the first patch into hjl/lto branch at > > http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary > > Now I can collect stage 2 command line. > I checked in a patch to implement stage 2 linking. Everything seems to work, including "gcc -static ... -lm". -- H.J.
Re: Update LTO plugin interface
On 04/12/2010 01:24, H.J. Lu wrote: > I checked in a patch to implement stage 2 linking. Everything > seems to work, including "gcc -static ... -lm". Any chance you could send a complete diff? cheers, DaveK
Re: Update LTO plugin interface
Dave Korn writes: > On 04/12/2010 01:24, H.J. Lu wrote: > >> I checked in a patch to implement stage 2 linking. Everything >> seems to work, including "gcc -static ... -lm". > > Any chance you could send a complete diff? I just want to note that I continue to think this is a really bad idea, and that we can easily fix the problems without going down this route. Also, if we do decide to go this route for some reason I can not currently fathom, we should completely revamp the plugin interface to make it much simpler. Any timing comparisons for working cases? Ian
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote: > On 04/12/2010 01:24, H.J. Lu wrote: > >> I checked in a patch to implement stage 2 linking. Everything >> seems to work, including "gcc -static ... -lm". > > Any chance you could send a complete diff? > I will submit a complete diff after I fix a few corner cases. In the meantime, you can clone my git tree and do a "git diff". -- H.J.
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote: > On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote: >> On 04/12/2010 01:24, H.J. Lu wrote: >> >>> I checked in a patch to implement stage 2 linking. Everything >>> seems to work, including "gcc -static ... -lm". >> >> Any chance you could send a complete diff? >> > > I will submit a complete diff after I fix a few corner cases. > In the meantime, you can clone my git tree and do a "git diff". > I checked a few more fixes into hjl/lto branch. The known issue: --whole-archive will call plugin on archives with IR in stage 2 linking. -- H.J.
PATCH: 2 stage BFD linker for LTO plugin
On Fri, Dec 3, 2010 at 6:34 PM, H.J. Lu wrote: > On Fri, Dec 3, 2010 at 6:23 PM, Dave Korn wrote: >> On 04/12/2010 01:24, H.J. Lu wrote: >> >>> I checked in a patch to implement stage 2 linking. Everything >>> seems to work, including "gcc -static ... -lm". >> >> Any chance you could send a complete diff? >> > > I will submit a complete diff after I fix a few corner cases. > In the meantime, you can clone my git tree and do a "git diff". > Hi, This patch implements 2 stage BFD linker for LTO plugin. It works with current LTO API on all cases I tested. Known issue: --whole-archive will call plugin on archives with IR in stage 2 linking. But ld never calls plugin to get back object files. I will try to avoid it in a follow up patch. OK for trunk? Thanks. -- H.J. --- bfd/ 2010-12-03 H.J. Lu PR driver/42690 * bfd.c (BFD_PLUGIN): New. (BFD_FLAGS_SAVED): Add BFD_PLUGIN. (BFD_FLAGS_FOR_BFD_USE_MASK): Likewise. * bfd-in2.h: Regenerated. ld/ 2010-12-03 H.J. Lu PR driver/42690 * ldfile.c (ldfile_try_open_bfd): Turn on BFD_PLUGIN and set claimed to false on non-object files and unclaimed object files. Set stage1. * ldlang.c (cmdline_list): New. (cmdline_next_claimed_output): Likewise. (cmdline_list_init): Likewise. (cmdline_get_stage2_input_files): Likewise. (debug_cmdline_list): Likewise. (cmdline_list_append): Likewise. (cmdline_set_next_claimed_output): Likewise. (cmdline_list_insert_claimed_output): Likewise. (new_afile): Set stage1 to FALSE; (lang_init): Call cmdline_list_init. (lang_process): Call plugin_active_plugins_p to check plugin support. Check cmdline_next_claimed_output before opening stage 2 input. Call debug_cmdline_list if trace_file_tries is set. Call cmdline_get_stage2_input_files to get stage 2 input files. * ldlang.h (lang_input_statement_struct): Add stage1. (cmdline_enum_type): New. (cmdline_header_type): Likewise. (cmdline_input_statement_type): Likewise. (cmdline_claimed_output_type): Likewise. (cmdline_union_type): Likewise. (cmdline_list_type): Likewise. (cmdline_list_append): Likewise. (cmdline_list_insert_claimed_output): Likewise. (cmdline_set_next_claimed_output): Likewise. * lexsup.c (parse_args): Call cmdline_list_append if needed. * plugin.c (plugin_opt_plugin_arg): Ignore -pass-through=. (add_input_file): Replace lang_add_input_file with cmdline_list_insert_claimed_output. (add_input_library): Likewise. ld/testsuite/ 2010-12-03 H.J. Lu PR driver/42690 * ld-plugin/func1i.c: New. * ld-plugin/func2.c: Likewise. * ld-plugin/func2h.c: Likewise. * ld-plugin/func3p.c: Likewise. * ld-plugin/plugin.exp: Add object files for symbols claimed or created by testplugin. * ld-plugin/plugin-7.d: Updated. * ld-plugin/plugin-8.d: Likewise. * ld-plugin/plugin-9.d: Likewise. bfd/ 2010-12-03 H.J. Lu PR driver/42690 * bfd.c (BFD_PLUGIN): New. (BFD_FLAGS_SAVED): Add BFD_PLUGIN. (BFD_FLAGS_FOR_BFD_USE_MASK): Likewise. * bfd-in2.h: Regenerated. ld/ 2010-12-03 H.J. Lu * ldfile.c (ldfile_try_open_bfd): Turn on BFD_PLUGIN and set claimed to false on non-object files and unclaimed object files. Set stage1. * ldlang.c (cmdline_list): New. (cmdline_next_claimed_output): Likewise. (cmdline_list_init): Likewise. (cmdline_get_stage2_input_files): Likewise. (debug_cmdline_list): Likewise. (cmdline_list_append): Likewise. (cmdline_set_next_claimed_output): Likewise. (cmdline_list_insert_claimed_output): Likewise. (new_afile): Set stage1 to FALSE; (lang_init): Call cmdline_list_init. (lang_process): Call plugin_active_plugins_p to check plugin support. Check cmdline_next_claimed_output before opening stage 2 input. Call debug_cmdline_list if trace_file_tries is set. Call cmdline_get_stage2_input_files to get stage 2 input files. * ldlang.h (lang_input_statement_struct): Add stage1. (cmdline_enum_type): New. (cmdline_header_type): Likewise. (cmdline_input_statement_type): Likewise. (cmdline_claimed_output_type): Likewise. (cmdline_union_type): Likewise. (cmdline_list_type): Likewise. (cmdline_list_append): Likewise. (cmdline_list_insert_claimed_output): Likewise. (cmdline_set_next_claimed_output): Likewise. * lexsup.c (parse_args): Call cmdline_list_append if needed. * plugin.c (plugin_opt_plugin_arg): Ignore -pass-through=. (add_input_file): Replace lang_add_input_file with cmdline_list_i
Re: Update LTO plugin interface
On Fri, Dec 3, 2010 at 6:15 PM, Ian Lance Taylor wrote: > Dave Korn writes: > >> On 04/12/2010 01:24, H.J. Lu wrote: >> >>> I checked in a patch to implement stage 2 linking. Everything >>> seems to work, including "gcc -static ... -lm". >> >> Any chance you could send a complete diff? > > I just want to note that I continue to think this is a really bad idea, > and that we can easily fix the problems without going down this route. > > Also, if we do decide to go this route for some reason I can not > currently fathom, we should completely revamp the plugin interface to > make it much simpler. The current API works OK with 2 stage BFD linker. My 2 stage BFD linker works with unmodified GCC 4.6. I will try to get it into binutils. Gold and ld can have different strategies for LTO plugin support as long as the same GCC driver binary works with both gold and ld binaries. > Any timing comparisons for working cases? > Here are timings to link GCC 4.6 cc1 on Core i7 870 2.93GHz: a. 1 stage linking: 409.94s user 5.48s system 99% cpu 6:58.88 total b. 2 stage linking: 410.08s user 5.53s system 98% cpu 7:00.00 total It isn't a real surprise since most times are spent in LTO plugin. Thanks. -- H.J.
