On Nov 17, 2005, at 6:33 PM, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Yeah, it's been sped up actually.
On Nov 17, 2005, at 6:13 PM, Daniel Jacobowitz wrote:
Also, please keep in mind that generating and then assembling debug
info takes a huge amount of I/O relative to code size. I'd expect
much
more than 1% saving the write-out and write-in on -g.
I'd hope that we can contribute code to elim
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
I never like arguments which have loaded words like "lot" without
quantification. Just how long *is* spent in this step, is it really
significant?
as is 2-3% as I recall (Finder_FE C++) of total build time.
On 11/18/05, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote:
> > A nightmare scenario is debugging the compiler when its behaviour
> > changes due to using "-S". Assembly source is something that we
> > maintainers use more than anyone else.
>
> I
Hi,
On Fri, 18 Nov 2005, Steven Bosscher wrote:
> On Friday 18 November 2005 17:31, Michael Matz wrote:
> > Perhaps even a merger of both
> > approaches is sensible, three address form for most simple gimple
> > statements with falling back to stack encoding for deeply nested operands.
>
> That
Kenneth Zadeck wrote:
The stack machine that we have in mind will be as stripped down as
possible. The idea is just to get the trees in and get them back out.
When I first read the proposal, I too wondered if a register machine would be
better here. I've come to the conclusion that it would
On Friday 18 November 2005 17:31, Michael Matz wrote:
> Perhaps even a merger of both
> approaches is sensible, three address form for most simple gimple
> statements with falling back to stack encoding for deeply nested operands.
That would be a bad violation of the KISS principle.
Gr.
Steven
Hi,
On Thu, 17 Nov 2005, Kenneth Zadeck wrote:
> A stack machine representation was chosen for the same reason. Tree
> gimple is a series of statements each statement being a tree.
IMHO we should follow that path of thinking. The representation of GIMPLE
where we do most optimizations on (i.e
On Fri, 2005-11-18 at 11:40 +, Andrew Haley wrote:
> A nightmare scenario is debugging the compiler when its behaviour
> changes due to using "-S". Assembly source is something that we
> maintainers use more than anyone else.
If we go the direct generation route, I think it would be more
effi
Richard Earnshaw writes:
> - Then, incrementally, we can bypass the parse layer to call routines
> directly in the assembler. This can be done both for directives and for
> assembly of instructions. *but it can all be done incrementally*.
>
> The main difficulty is preserving -S output in
On Fri, 2005-11-18 at 09:29, Bernd Schmidt wrote:
> > Also, please keep in mind that generating and then assembling debug
> > info takes a huge amount of I/O relative to code size. I'd expect much
> > more than 1% saving the write-out and write-in on -g.
>
> So, maybe a simpler strategy could be
Bernd Schmidt wrote:
So, maybe a simpler strategy could be to make minor modifications to gas
and gcc so that the former is linked in and the latter can pass strings
to it? Maybe that could get us a performance improvement without the
need for a massive overhaul of all backends, and the need
Daniel Jacobowitz wrote:
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
I just tried a simple unoptimized compile. -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time
On Nov 17, 2005, at 21:33, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Don't know if that's still accurate. Of course the speed of the
assembler
is also relevant, and our stubs a
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
Richard Earnshaw wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the
assembler.
I never like arguments which have loaded words like "lot" without
quantification
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
> I just tried a simple unoptimized compile. -ftime-report said that
> final took 5% of the time (obviously final does more than formatting),
> and the assembler took 4% of the total user time, and system time took
> 16% of wall clo
Robert Dewar <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> >>We spend a lot of time printing out the results of compilation as
> >> assembly language, only to have to parse it all again in the
> >> assembler.
>
> I never like arguments which have loaded words like "lot" without
> qua
Ian Lance Taylor wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the assembler.
I never like arguments which have loaded words like "lot" without
quantification. Just how long *is* spent in this step, is it real
Ulrich Weigand <[EMAIL PROTECTED]> writes:
> > Conversely, I don't know much we are going to care about speed here,
> > but I assume that we are going to care a bit. For the linker to
> > determine which files to pull in from an archive, it is going to have
> > to read the symbol tables of all th
Richard Earnshaw <[EMAIL PROTECTED]> writes:
> We spend a lot of time printing out the results of compilation as
> assembly language, only to have to parse it all again in the assembler.
> Given some of the problems this proposal throws up I think we should
> seriously look at bypassing as much o
> On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > > http://gcc.gnu.org/projects/lto/lto.pdf
> >
> > Section 4.2
> >
> > What is the rationale for using a stack-based representation rather
> > than a register-based representation? A infinite register based
> > solution
> >> Thanks for woking on this. Any specific reason why using the LLVM
> >> bytecode wasn't taken into account?
> >
> > It was.
> > A large number of alternatives were explored, including CIL, the JVM,
> > LLVM, etc.
> >
> >> It is proven to be stable, high-level enough to
> >> perform any kind of
Mark Mitchell <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2 (Executable Representation) describes the GVM as a stack
> machine, and mentions load, store, duplicate, and swap operations.
> But it also discusses having registers which correspond to GIMPLE
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2
>
> What is the rationale for using a stack-based representation rather
> than a register-based representation? A infinite register based
> solution would seem to ma
hi,
Daniel Berlin wrote:
I discovered this when deep hacking into the symbol code of GDB a while
ago. Apparently, some people enjoy breakpointing symbols by using the
fully mangled name, which appears (nowadays) mainly in the minsym table.
This sort of hack is often used to work around what
On Wed, 2005-11-16 at 20:33 -0700, Jeffrey A Law wrote:
> > Our understanding was that the debugger actually uses the symbol table,
> > in addition to the debugging information, in some cases. (This must be
> > true when not running with -g, but I thought it was true in other cases
> > as well.)
Ian Lance Taylor wrote:
> In section 3.4 (Linker) I have the same comment: for non-GNU targets,
> the native linker is sometimes required, so modifying the linker
> should not be a requirement. And the exact handling of .a files is
> surprisingly target dependent, so while it would be easy to cod
On Thu, 2005-11-17 at 01:27, Mark Mitchell wrote:
> Richard Henderson wrote:
> > In Requirement 4, you say that the function F from input files a.o and
> > b.o should still be named F in the output file. Why is this requirement
> > more than simply having the debug information reflect that both na
Daniel Berlin <[EMAIL PROTECTED]> wrote:
>> Thanks for woking on this. Any specific reason why using the LLVM
>> bytecode wasn't taken into account?
>
> It was.
> A large number of alternatives were explored, including CIL, the JVM,
> LLVM, etc.
>
>> It is proven to be stable, high-level enough to
Mark Mitchell <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/projects/lto/lto.pdf
Section 2.2.1 (Variables and Functions) mentions C++ inline functions.
It should also mention gcc's C language "extern inline" functions.
The same section should consider common symbols. These appear as
uninit
> Our understanding was that the debugger actually uses the symbol table,
> in addition to the debugging information, in some cases. (This must be
> true when not running with -g, but I thought it was true in other cases
> as well.) It might be true for other tools, too.
I can't offhand recall i
The document is on the web here:
http://gcc.gnu.org/projects/lto/lto.pdf
The LaTeX sources are in htdocs/projects/lto/*.tex.
Thoughts?
It may be worth mentioning that this type of optimization
applies mainly to one given type of output: a non-symbolic
a.out. When the output it a shared libr
Some more comments (this time section by section and a little more thought out):
2.1:
Requirement 1: a good question is how does ICC or even XLC
do this without doing anything special? Or do they keep around
an "on-the-side" database.
(Requirements 2-4 assume Requirement 1)
Requirement 5: is pe
Mark Mitchell <[EMAIL PROTECTED]> writes:
| The GCC community has talked about link-time optimization for some time.
| In addition to results with other compilers, Geoff Keating's work on
| inter-module optimization has demonstrated the potential for improved
| code-generation from applying optimi
On Wed, Nov 16, 2005 at 05:27:58PM -0800, Mark Mitchell wrote:
> > In Requirement 4, you say that the function F from input files a.o and
> > b.o should still be named F in the output file. Why is this requirement
> > more than simply having the debug information reflect that both names
> > were o
Richard Henderson wrote:
In general, I'm going to just collect comments in a folder for a while,
and then try to reply once the dust has settled a bit. I'm interested
in seeing where things go, and my primary interest is in getting *some*
consensus, independent of a particular one.
But, I'll try
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> http://gcc.gnu.org/projects/lto/lto.pdf
In Requirement 4, you say that the function F from input files a.o and
b.o should still be named F in the output file. Why is this requirement
more than simply having the debug information r
Daniel Berlin Wrote:
> > It [LLVM] is proven to be stable, high-level enough to
> > perform any kind of needed optimization,
> This is not true, unfortunately. That's why it is called "low
level virtual machine".
> It doesn't have things we'd like to do high level optimizations
on, like
> d
> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes:
Andrew> One thing not mentioned here is how are you going to repesent
Andrew> different eh personality functions between languages, because
Andrew> currently we cannot even do different ones in the same
Andrew> compiling at all.
I think
On Thu, 2005-11-17 at 01:26 +0100, Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> > Thoughts?
>
>
> Thanks for woking on this. Any specific reason why using the LLVM bytecode
> wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL,
Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Thoughts?
Thanks for woking on this. Any specific reason why using the LLVM bytecode
wasn't taken into account? It is proven to be stable, high-level enough to
perform any kind of needed optimization, and already features interpreters,
JITters and whatn
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
One t
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
I don
> Some of us (Dan Berlin, David Edelsohn, Steve Ellcey, Shin-Ming Liu,
> Tony Linthicum, Mike Meissner, Kenny Zadeck, and myself) have developed
> a high-level proposal for doing link-time optimization in GCC. At this
> point, this is just a design sketch. We look forward to jointly
> developing
>
> The GCC community has talked about link-time optimization for some time.
> In addition to results with other compilers, Geoff Keating's work on
> inter-module optimization has demonstrated the potential for improved
> code-generation from applying optimizations across translation units.
>
> O
45 matches
Mail list logo
