On Fri, May 31, 2013 at 4:12 PM, David Malcolm wrote:
> On Tue, 2013-05-28 at 12:30 -0600, Jeff Law wrote:
>> On 05/28/2013 11:00 AM, David Malcolm wrote:
>> > On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
>> >> On 05/25/2013 07:02 AM, David Malcolm wrote:
>> >>> I can think of three approach
On 05/28/2013 11:00 AM, David Malcolm wrote:
On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun
On Tue, 2013-05-28 at 06:39 -0600, Jeff Law wrote:
> On 05/25/2013 07:02 AM, David Malcolm wrote:
> > I can think of three approaches to "cfun":
> > (a) status quo: a global variable, with macros to prevent direct
> > assignment, and an API for changing cfun.
> > (b) have a global "context" or
On 05/25/2013 07:02 AM, David Malcolm wrote:
I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun.
(b) have a global "context" or "universe" object, and put cfun in
there (perhaps with tricks
On Mon, May 27, 2013 at 3:41 PM, Jan Hubicka wrote:
>>
>> I think that was one reason crtl was introduced ... to avoid an indirection
>> through cfun.
>
> Main reason why I introduced crtl was to get struct function less bloated.
> RTL data live for only one function body at a time. It is useless
>
> I think that was one reason crtl was introduced ... to avoid an indirection
> through cfun.
Main reason why I introduced crtl was to get struct function less bloated.
RTL data live for only one function body at a time. It is useless to store them
in a datastructure that is allocated at parsin
On Sat, May 25, 2013 at 9:33 PM, Jan Hubicka wrote:
>> Here's an idea that could make it easier to remove the "cfun" global.
>>
>> "cfun" is a major piece of global state within gcc: it's the 5th most
>> accessed variable in the build (accessed in ~4600 places within one stage
>> of a build, based
> Here's an idea that could make it easier to remove the "cfun" global.
>
> "cfun" is a major piece of global state within gcc: it's the 5th most
> accessed variable in the build (accessed in ~4600 places within one stage
> of a build, based on [1]). This is an obstacle to making gcc's code be
>
Here's an idea that could make it easier to remove the "cfun" global.
"cfun" is a major piece of global state within gcc: it's the 5th most
accessed variable in the build (accessed in ~4600 places within one stage
of a build, based on [1]). This is an obstacle to making gcc's code be
usable as a
