Article: MAQSIP-RT: An HPC Benchmark
By: rwessel (robertwessel.delete@this.yahoo.com), July 2, 2010 2:32 pm
Room: Moderated Discussions
Max (max@a.com) on 7/2/10 wrote:
---------------------------
>Max (max@a.com) on 7/2/10 wrote:
>---------------------------
>>rwessel (robertwessel@yahoo.com) on 7/2/10 wrote:
>>---------------------------
>>>In any event, LTCG is the solution to the optimization issue.
>>
>>If you don't care about compile speed, you can just compile everything at once.
>>That's simpler and more effective than duplicating parts of the compiler in the linker.
>
>On second thought, compile everything at once (starting from the intermediate language,
>not source) is probably exactly what you meant by LTCG. That is, LTCG is not enhanced
>traditional linking, it's a full blown compile with link semantics. Right?
Typically Link Time Code Generation works by having the compiler store the intermediate representation (usually something along the lines of the parse tree) in the "object" file, rather than passing it to the back end of the compiler for turning into object code. Usually the object file contains the name of the required back end (MSVC, for example, stores the full directory and file name of the compiler back end DLL).
The linker then collects all the intermediate "code" objects destined for a given back end, and passes then to that (actual) compiler back end, which then (typically) generates a "real" object file, which the linker then handles as usual. Other “real” object files are handled in the traditional way.
This usually has minimal impact on either the linker or compiler. The compiler back end has to handle names a bit differently (basically static names now need additional qualification), but not too much. The linker obviously has to recognize the new format, and deal with that, but usually then just has to deal with a normal object file.
I'm not sure what you mean by "compile all at once." Typically invoking the compiler with the command line specifying several source modules does *not* provide for any sort of inter-translation unit optimization, it just automatically compiles each source module as if you had invoked the compiler several times. It would, however, not be at all unreasonable for the compiler to invoke LTCG in such a case, but I don’t know of anyone who does that.
---------------------------
>Max (max@a.com) on 7/2/10 wrote:
>---------------------------
>>rwessel (robertwessel@yahoo.com) on 7/2/10 wrote:
>>---------------------------
>>>In any event, LTCG is the solution to the optimization issue.
>>
>>If you don't care about compile speed, you can just compile everything at once.
>>That's simpler and more effective than duplicating parts of the compiler in the linker.
>
>On second thought, compile everything at once (starting from the intermediate language,
>not source) is probably exactly what you meant by LTCG. That is, LTCG is not enhanced
>traditional linking, it's a full blown compile with link semantics. Right?
Typically Link Time Code Generation works by having the compiler store the intermediate representation (usually something along the lines of the parse tree) in the "object" file, rather than passing it to the back end of the compiler for turning into object code. Usually the object file contains the name of the required back end (MSVC, for example, stores the full directory and file name of the compiler back end DLL).
The linker then collects all the intermediate "code" objects destined for a given back end, and passes then to that (actual) compiler back end, which then (typically) generates a "real" object file, which the linker then handles as usual. Other “real” object files are handled in the traditional way.
This usually has minimal impact on either the linker or compiler. The compiler back end has to handle names a bit differently (basically static names now need additional qualification), but not too much. The linker obviously has to recognize the new format, and deal with that, but usually then just has to deal with a normal object file.
I'm not sure what you mean by "compile all at once." Typically invoking the compiler with the command line specifying several source modules does *not* provide for any sort of inter-translation unit optimization, it just automatically compiles each source module as if you had invoked the compiler several times. It would, however, not be at all unreasonable for the compiler to invoke LTCG in such a case, but I don’t know of anyone who does that.
Topic | Posted By | Date |
---|---|---|
New article online: MAQSIP RT | David Kanter | 2010/06/21 10:57 AM |
Why no GCC? | Rohit | 2010/06/22 08:25 PM |
Why no GCC? | David Kanter | 2010/06/22 11:45 PM |
sun 's cc better than GCC? | Rohit | 2010/06/23 04:04 AM |
sun 's cc better than GCC? | anon | 2010/06/23 06:49 AM |
Where is the GCC optimization effort directed? | Mark Roulo | 2010/06/23 09:42 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/23 01:49 PM |
even for 64-bit arch? | anon | 2010/06/23 01:59 PM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/23 10:03 PM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 01:33 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 04:32 AM |
GCC is very ugly bad everywhere in 64 bits | Gabriele Svelto | 2010/06/24 06:18 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:50 AM |
Why GCC is big and complicated (my guess) | Mark Roulo | 2010/06/24 11:17 AM |
Why GCC is big and complicated (my guess) | Gabriele Svelto | 2010/06/28 03:00 AM |
GCC is very ugly bad everywhere in 64 bits | Bernd Schmidt | 2010/06/24 04:46 AM |
GCC is very ugly bad everywhere in 64 bits | ajensen | 2010/06/24 08:43 AM |
GCC is very ugly bad everywhere in 64 bits | Vincent Diepeveen | 2010/06/26 01:12 PM |
GCC is very ugly bad everywhere in 64 bits | Rob Thorpe | 2010/06/24 06:47 AM |
GCC is very ugly bad everywhere in 64 bits | Anon | 2010/06/24 04:23 PM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/23 09:45 PM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 12:48 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 01:29 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 02:13 AM |
Where is the GCC optimization effort directed? | Andi Kleen | 2010/06/24 02:15 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:08 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 02:54 AM |
Where is the GCC optimization effort directed? | ? | 2010/06/24 03:15 AM |
Where is the GCC optimization effort directed? | Gabriele Svelto | 2010/06/24 06:22 AM |
Where is the GCC optimization effort directed? | Rohit | 2010/06/24 02:04 AM |
Placebo effect | ? | 2010/06/24 05:37 AM |
Placebo effect | Rohit | 2010/06/24 07:45 AM |
Placebo effect | Vincent Diepeveen | 2010/06/26 01:50 PM |
Compile time | Mark Roulo | 2010/06/26 04:28 PM |
Compile time | Richard Cownie | 2010/06/27 03:44 AM |
Compile time | Mark Roulo | 2010/06/27 09:12 AM |
Compile time | Mark Roulo | 2010/06/27 09:21 AM |
Compile time | EduardoS | 2010/06/27 10:37 AM |
Compile time | Richard Cownie | 2010/06/27 03:07 PM |
Compile time & efficiency | ? | 2010/06/27 11:03 PM |
Compile time & efficiency | Mark Christiansen | 2010/06/28 05:08 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 06:48 AM |
kernel programming language | John Simon | 2010/06/29 05:46 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 08:29 AM |
Compile time & efficiency | Linus Torvalds | 2010/06/28 10:17 AM |
Compile time & efficiency | Richard Cownie | 2010/06/28 01:16 PM |
Compile time & efficiency | Richard Cownie | 2010/06/28 05:23 PM |
Compile time & efficiency | Mark Roulo | 2010/06/29 07:31 AM |
Compile time & efficiency | Richard Cownie | 2010/06/29 10:48 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:28 AM |
C is a crappy | dev | 2010/06/29 06:12 PM |
C is a crappy, but only when you push it out of it's niche | Rohit | 2010/06/30 01:11 AM |
C is a crappy | anon | 2010/06/30 01:17 AM |
C is a crappy | dev | 2010/06/30 06:59 AM |
C is a crappy | Max | 2010/07/01 03:30 AM |
C is a crappy | Michael S | 2010/07/01 06:00 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 07:02 AM |
C is a crappy | Michael S | 2010/07/01 07:50 AM |
C isn't so crappy | anon | 2010/07/01 09:11 AM |
C isn't so crappy | Mikael Tillenius | 2010/07/01 10:39 AM |
C is a crappy | Konrad Schwarz | 2010/07/01 10:22 AM |
C is a crappy | Max | 2010/07/02 07:44 AM |
C is a crappy | rwessel | 2010/07/02 11:33 AM |
C is a crappy | anon | 2010/07/02 12:17 PM |
C is a crappy | Max | 2010/07/02 01:56 PM |
C is a crappy | Max | 2010/07/02 02:13 PM |
C is a crappy | rwessel | 2010/07/02 02:32 PM |
C is a crappy | Max | 2010/07/02 03:19 PM |
C is a crappy | Gabriele Svelto | 2010/07/05 04:25 AM |
C is a crappy | gallier2 | 2010/07/01 11:14 PM |
C is a crappy | Ian Ollmann | 2010/07/06 02:07 PM |
Portability | Max | 2010/07/06 02:37 PM |
C is a crappy | hobold | 2010/07/07 01:31 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:18 PM |
failure to standardize types | Carlie Coats | 2010/07/07 03:11 AM |
C is a crappy | Konrad Schwarz | 2010/07/07 07:34 AM |
C is a crappy | Ian Ollmann | 2010/07/07 04:29 PM |
C is a crappy NOT | Konrad Schwarz | 2010/07/07 11:29 PM |
C is a crappy | anon | 2010/07/01 09:40 PM |
C type safety | ? | 2010/07/02 12:10 AM |
C type safety | anon | 2010/07/02 10:02 PM |
C is a crappy | dev | 2010/07/03 03:51 PM |
C is a crappy | anon | 2010/07/03 06:02 PM |
C is a crappy | dev | 2010/07/05 06:27 AM |
C is a crappy | ? | 2010/07/05 08:05 AM |
C is a crappy | anonymous | 2010/07/07 07:32 AM |
C is a crappy | ? | 2010/07/07 09:48 PM |
C is a crappy | Anon | 2010/07/07 11:53 PM |
C is a crappy and a crappie is a fish | anonymous | 2010/07/03 06:24 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:18 AM |
Compile time & efficiency | rwessel | 2010/06/29 11:20 AM |
Compile time & efficiency | someone | 2010/06/30 10:03 AM |
Compile time & efficiency | Jouni Osmala | 2010/07/02 04:29 AM |
Compile time & efficiency | Max | 2010/06/28 04:05 PM |
Compile time & efficiency | EduardoS | 2010/06/28 04:11 PM |
Compile time & efficiency | Michael S | 2010/06/29 02:33 AM |
Compile time | Foo_ | 2010/06/28 08:03 AM |
sun 's cc better than GCC? | Silent | 2010/06/23 05:19 PM |
sun 's cc better than GCC? | Foo_ | 2010/06/23 06:06 PM |
sun 's cc better than GCC? | Andi Kleen | 2010/06/24 01:49 AM |
sun 's versus gcc | Vincent Diepeveen | 2010/06/23 02:07 PM |
Why no GCC? | Carlie Coats | 2010/06/23 04:11 AM |