On Fri, Jun 13, 2008 at 12:29 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 6/13/08 3:27 AM, Richard Guenther wrote:
>
>> But probably pulling them in on-demand is
>> a more practical approach (after all this huge number of vars is
>> also the cause of the slowness of alias computation and part
On 6/13/08 3:27 AM, Richard Guenther wrote:
But probably pulling them in on-demand is
a more practical approach (after all this huge number of vars is
also the cause of the slowness of alias computation and partitioning
in this testcase).
I agree, and the end result would be the same. By the
On 6/12/08 6:49 PM, Daniel Berlin wrote:
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
int N;
int foobar;
int *bar = &foobar;
int **foo = &bar;
x ()
{
int **x = foo;
return **x;
}
All of 'foobar', 'bar' and 'foo' will be in the list of symbols
referenced by x().
On Fri, Jun 13, 2008 at 12:49 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>>
>>> I have no idea how to make sure, in whopr, that function x sees foobar if
>>> yo
On Thu, Jun 12, 2008 at 4:39 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> I have no idea how to make sure, in whopr, that function x sees foobar if
>> you are going to cherry pick the globals also.
>
> I'm not sure I see the problem t
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I have no idea how to make sure, in whopr, that function x sees foobar if
> you are going to cherry pick the globals also.
I'm not sure I see the problem that you are pointing to. In this program:
int N;
int foobar;
int *bar = &foobar;
Diego Novillo wrote:
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I think that if you want to cast this as we need to have a symbol table for
the compiler in general then that is fine.
Yes, but we only need a symbol table for globals. Temporaries and
locals need not be i
On 2008-06-12, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I think that if you want to cast this as we need to have a symbol table for
> the compiler in general then that is fine.
Yes, but we only need a symbol table for globals. Temporaries and
locals need not be in this table.
> However, th
On 2008-06-12, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Yes. The referenced_vars hashtable is filled by the referenced_vars pass
> (see tree-dfa.c:find_referenced_vars).
Right, that's why Ken's reference to pass_ipa_reference() confused me.
find_referenced_vars() is probably the oldest an
Diego Novillo wrote:
On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
my sense is not to associate put this directly in the cgraph but to keep it
as a side table that is indexed by something like the cgraph node id. The
reason for leaning in this direction is that "what happens in
On Thu, Jun 12, 2008 at 1:24 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> my sense is not to associate put this directly in the cgraph but to keep it
>> as a side table that is indexed by something like the cgraph node id. The
>> re
On 2008-06-11, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> my sense is not to associate put this directly in the cgraph but to keep it
> as a side table that is indexed by something like the cgraph node id. The
> reason for leaning in this direction is that "what happens in the cgraph
> stays i
Richard Guenther wrote:
On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[E
On Thu, Jun 12, 2008 at 3:53 AM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>>
>> On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Richard Guenther wrote:
>>>
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wro
Daniel Berlin wrote:
On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote:
Doug,
Yesterday, we spoke briefly about the need to efficiently determine
the DECL's
On Wed, Jun 11, 2008 at 9:13 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>>
>> On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Doug,
>>>
>>> Yesterday, we spoke briefly about the need to efficiently determine
>>> the DECL's required by
Richard Guenther wrote:
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote:
Doug,
Yesterday, we spoke briefly about the need to efficiently determine
the DECL's required by each function. Here's a more detailed
overview. During the WPA phase of WHOPR, we will be reading
On Wed, Jun 11, 2008 at 11:33 PM, Ollie Wild <[EMAIL PROTECTED]> wrote:
> Doug,
>
> Yesterday, we spoke briefly about the need to efficiently determine
> the DECL's required by each function. Here's a more detailed
> overview. During the WPA phase of WHOPR, we will be reading in a
> collection of
Doug,
Yesterday, we spoke briefly about the need to efficiently determine
the DECL's required by each function. Here's a more detailed
overview. During the WPA phase of WHOPR, we will be reading in a
collection of object files, performing analysis on call-graph/summary
data, and outputting repac
19 matches
Mail list logo
