Andrew Pinski wrote:
> On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
>
>>> +#if STUPID_TYPE_SYSTEM
>>>
>>>
>> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
>>
>
> Well it right now it is stupid, this is just a work around anyways until
> people fix the typ
On Fri, 2006-09-01 at 09:51 -0400, Diego Novillo wrote:
>
> > +#if STUPID_TYPE_SYSTEM
> >
> STUPID_TYPE_SYSTEM? No need to be insulting. It's unpleasant.
Well it right now it is stupid, this is just a work around anyways until
people fix the type mismatches really. Is it more insulting than ha
Diego Novillo wrote:
> Kenneth Zadeck wrote on 08/28/06 09:57:
>
>
>> I have not done this because I do not rule the earth. That was not
>> what I was assigned to do, and I agreed that DWARF3 sounded like a
>> reasonable way to go. Now that I understand the details of DWARF3, I
>> have changed
On Fri, Sep 01, 2006 at 10:19:07AM -0400, Kenneth Zadeck wrote:
> Daniel Jacobowitz wrote:
> > On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
> >
> >> Given that Mark, and for that matter no one else, did not really push
> >> back, I am pretty much committed not to use dwarf.
>
Daniel Jacobowitz wrote:
> On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
>
>> Given that Mark, and for that matter no one else, did not really push
>> back, I am pretty much committed not to use dwarf.
>>
>
> Then... what are you going to do about things like types? Inve
On Fri, Sep 01, 2006 at 09:45:34AM -0400, Kenneth Zadeck wrote:
> Given that Mark, and for that matter no one else, did not really push
> back, I am pretty much committed not to use dwarf.
Then... what are you going to do about things like types? Invent a new
serialization for those too? I thin
Kenneth Zadeck wrote on 08/28/06 09:57:
> I have not done this because I do not rule the earth. That was not
> what I was assigned to do, and I agreed that DWARF3 sounded like a
> reasonable way to go. Now that I understand the details of DWARF3, I
> have changed my mind about the correct direct
Daniel Jacobowitz wrote:
> On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
>
>> I think this is probably moot, since I believe that Kenny feels DWARF is
>> not suitable for reasons other than the abbreviation table issue, but
>> this is a clever technique.
>>
>
> ... for GI
On Thu, Aug 31, 2006 at 04:00:25PM -0700, Mark Mitchell wrote:
> I think this is probably moot, since I believe that Kenny feels DWARF is
> not suitable for reasons other than the abbreviation table issue, but
> this is a clever technique.
... for GIMPLE; when I discussed with him, I got the imp
mathieu lacage wrote:
I have spent a considerable amount of time looking at the abbrev tables
output by gcc are not totally random: their entries are sorted by their
abbrev code. That is, the abbrev code of entry i+1 is higher than that
of entry i.
That's an interesting observation. Essential
Daniel Jacobowitz wrote:
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
Here, we won't be making syscalls
Yes, you almost certainly will.
OK, good point.
In any case, my concern is that we're worrying a lot about on-disk
encoding, but that there are lots of other hard probl
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> I am not so concerned with running out of virtual address space than I
>> am about being able to break this up so that it can be done in parallel,
>> on a farm of machines. Otherwise, lto can never be part of anyone's
>> compile/test loop.
>
> I t
Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we just expanded the scope of w
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
> Here, we won't be making syscalls
Yes, you almost certainly will. If you've got a thousand object files,
you probably don't want to keep them all opened all the time; there are
these pesky things like open file descriptor limits, fo
Daniel Berlin wrote:
On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions
that
>> are going to be inl
On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function b
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function being compiled. Getting at
>> those functions that are g
hi,
On Wed, 2006-08-30 at 16:44 -0500, Mark Mitchell wrote:
[snip]
> (Implied, but not stated, in your mail is the fact that the abbreviation
> table cannot be indexed directly. If it could be, then you wouldn't
> have to read the entire abbreviation table for each function; you would
> just
On 8/30/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
...
I guess my overriding concern is that we're focusing heavily on the data
format here (DWARF? Something else? Memory-mappable? What compression
scheme?) and we may not have enough data. I guess we just have to pick
something and run with
Kenneth Zadeck wrote:
Even if we decide that we are going to process all of the functions in
one file at one time, we still have to have access to the functions that
are going to be inlined into the function being compiled. Getting at
those functions that are going to be inlined is where the do
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>
>
>> This
>> will be more cumbersome if we have to keep reloading each object
>> file's abbrev table just to tear apart a single function in that .o
>> file. While the abbrev sections average slightly less than %2 of the
>> of the size of the GIMPLE
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
[I'm sorry for not replying to this sooner. I've been on a plane or in
a meeti
> [...]
> KZ> +case TRUTH_NOT_EXPR:
> KZ> +case VIEW_CONVERT_EXPR:
> KZ> +#if STUPID_TYPE_SYSTEM
> KZ> + output_type_ref (ob, TREE_TYPE (expr));
> KZ> +#endif
>
> I think VIEW_CONVERT_EXPR needs to be treated like NOP_EXPR and
> CONVERT_EXPR in the STUPID_TYPE_SYSTEM case. VIEW_CONVE
> "KZ" == Kenneth Zadeck <[EMAIL PROTECTED]> writes:
KZ> 2) To have a discussion about the use of DWARF3. I am now against the
KZ> use of DWARF3 for encoding the GIMPLE.
FWIW your arguments convinced me.
I think what matters most is that the resulting format be relatively
well documented (s
Michael Eager wrote:
> Kenneth Zadeck wrote:
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to files.
>
> I have only a limited understanding of GIMPLE and
Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
I have only a limited understanding of GIMPLE and LTO, but here are my
comments r
On Aug 28, 2006, at 10:36 AM, Kenneth Zadeck wrote:
I actually do not think that it is productive to spend that much time
measuring this until we first assure ourselves that we are getting all
of the information output correctly. That 60mb number will change
a lot
(both up and down) as we get
Chris Lattner wrote:
> On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
>
>> This posting is a progress report of my task of encoding and decoding
>> the GIMPLE stream into LTO. Included in this posting is a patch that
>> encodes functions and dumps the result to files.
>
> Interesting email.
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote:
This posting is a progress report of my task of encoding and decoding
the GIMPLE stream into LTO. Included in this posting is a patch that
encodes functions and dumps the result to files.
Interesting email. One question: how big are the fil
29 matches
Mail list logo
