On Thu, 8 Apr 2010, Jan Hubicka wrote:
:) We need debug info and hammer out all bugs of course! I would also like to
see possiblity to LTO bootstrap without gold and possibility to not generate
assembly into LTO .o files. In the typical use where one builds app with LTO
(such as bootstrap)
On Fri, 9 Apr 2010, Jan Hubicka wrote:
On Thu, 8 Apr 2010, Jan Hubicka wrote:
:) We need debug info and hammer out all bugs of course! I would also
like to
see possiblity to LTO bootstrap without gold and possibility to not
generate
assembly into LTO .o files. In the
On Thu, 8 Apr 2010, Jan Hubicka wrote:
:) We need debug info and hammer out all bugs of course! I would also like
to
see possiblity to LTO bootstrap without gold and possibility to not generate
assembly into LTO .o files. In the typical use where one builds app with
LTO
(such as
On Fri, 9 Apr 2010, Jan Hubicka wrote:
On Thu, 8 Apr 2010, Jan Hubicka wrote:
:) We need debug info and hammer out all bugs of course! I would also
like to
see possiblity to LTO bootstrap without gold and possibility to not
generate
assembly into LTO .o files. In
On Fri, Apr 9, 2010 at 04:21, Richard Guenther rguent...@suse.de wrote:
Well, but it's pretty much deep-rooted into the LTO design as we use
collect2 and/or gold to do symbol resolution which of course needs
object code. I can imagine we can nuke the collect2 stuff looking
at symbols, but
Hello,
I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled.
Not sure what happened, other than that my machine ran out of memory.
I guess this is kind-of expected, but it made me wondering how much
work, and what exactly, remains to be done before bootstrapping with
WHOPR enabled
On Thu, Apr 8, 2010 at 12:32 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled.
Not sure what happened, other than that my machine ran out of memory.
I guess this is kind-of expected, but it made me wondering how much
On Thu, Apr 8, 2010 at 06:32, Steven Bosscher stevenb@gmail.com wrote:
I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled.
Not sure what happened, other than that my machine ran out of memory.
I guess this is kind-of expected, but it made me wondering how much
work, and
On Thu, Apr 08, 2010 at 09:13:45AM -0400, Diego Novillo wrote:
Perhaps the easiest option is to remove the feature. WHOPR does not
represent a lot of code over the basic LTO framework, so this should
be relatively easy and non-intrusive.
The first target I would shoot for, however, is to
On Thu, 8 Apr 2010, Diego Novillo wrote:
On Thu, Apr 8, 2010 at 06:32, Steven Bosscher stevenb@gmail.com wrote:
I've tried, unsuccessfully, bootstrapping C only with WHOPR enabled.
Not sure what happened, other than that my machine ran out of memory.
I guess this is kind-of expected,
On Thu, Apr 8, 2010 at 09:25, Basile Starynkevitch
bas...@starynkevitch.net wrote:
I am bit confused by this last sentence. Isn't it already the case in
gcc 4.5 that using -flto both at compile and at link times (usually a
trivial way to do that might be make CC='gcc-4.5 -flto -O2' or
It was. Unfortunately,work on it stopped last year and it is unlikely
that I will be assigned to this again. I still have some personal
interest on the feature, but given time restrictions, we should make
contingency plans.
Perhaps the easiest option is to remove the feature. WHOPR does
Well, I think this is independent.
It makes a lot of sense to make profiling to work in a way so instrumentation
happens at linktime with LTO and we can read stuff back. This is relatively
easy to do: we need to rewrite profiling pass to work on SSA (that is easy and
desirable anyway and on
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is available. Much like we do with other optimization
decisions. They transparently
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is available. Much like we do with other optimization
decisions. They
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a
mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is available. Much like we do with other optimization
decisions. They
On 4/8/10 14:30 , Jan Hubicka wrote:
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a
mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is available. Much like we do with other
On 4/8/10 14:30 , Jan Hubicka wrote:
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a
mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is available. Much like we do with
On 4/8/10 14:34 , Jan Hubicka wrote:
On 4/8/10 14:30 , Jan Hubicka wrote:
On 4/8/10 14:10 , Jan Hubicka wrote:
So I think tying WHOPR and profile feedback too close together is a
mistake.
Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
information if it is
Diego, thanks for brining LIPO into discussion.
There is a common misunderstanding of LIPO. It is not about
partitioning, but about extending single module compilation scope to
multiple/cross module. For instance for a build with a.c, b.c, c.c,
and d.c, LIPO does not partition them into
{a.c b.c}
On Thu, Apr 8, 2010 at 14:53, Xinliang David Li davi...@google.com wrote:
Diego, thanks for brining LIPO into discussion.
There is a common misunderstanding of LIPO. It is not about
partitioning, but about extending single module compilation scope to
multiple/cross module. For instance for a
21 matches
Mail list logo
