inlining default

inlining default

[Jason Merrill]

It seems that Neil's 2001-11-15 changes to option parsing had a side effect
of turning on tree inlining at -O0 for C and C++ unless suppressed with
-fno-inline, because we now set flag_tree_inline from flag_no_inline before
setting flag_no_inline from optimize.  Is this what we want?  I would
prefer to leave it off by default with -O0, but many compilers turn it on
unless specifically disabled.  What do other people think?

Jason

Re: inlining default

[Bo Thorsen]

On Wednesday 12 December 2001 15:00, Jason Merrill wrote:
> It seems that Neil's 2001-11-15 changes to option parsing had a side effect
> of turning on tree inlining at -O0 for C and C++ unless suppressed with
> -fno-inline, because we now set flag_tree_inline from flag_no_inline before
> setting flag_no_inline from optimize.  Is this what we want?  I would
> prefer to leave it off by default with -O0, but many compilers turn it on
> unless specifically disabled.  What do other people think?

Is this related to the ICE I reported with latest CVS:

*** ice.c ***

typedef struct { long p; } pt;

inline pt f(pt _p)
{
  long p = _p.p;

  return (pt) { (p) };
}

static int mmap_mem(void)
{
  pt p;
  p = f(p);

  return 0;
}

*** ice.c ***

"gcc ice.c" gives an ICE on i386, ia-64 and x86-64 (at least) and prevents 
kernel, glibc and X compilation. Remove the inline keyword and it does fine.

I have been hunting for the exact patch that started this, but you came with 
this so I thought I would ask.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: inlining default

[Jakub Jelinek]

On Wed, Dec 12, 2001 at 04:44:50PM +0100, Bo Thorsen wrote:
> On Wednesday 12 December 2001 15:00, Jason Merrill wrote:
> > It seems that Neil's 2001-11-15 changes to option parsing had a side effect
> > of turning on tree inlining at -O0 for C and C++ unless suppressed with
> > -fno-inline, because we now set flag_tree_inline from flag_no_inline before
> > setting flag_no_inline from optimize.  Is this what we want?  I would
> > prefer to leave it off by default with -O0, but many compilers turn it on
> > unless specifically disabled.  What do other people think?
> 
> Is this related to the ICE I reported with latest CVS:
> 
> *** ice.c ***
> 
> typedef struct { long p; } pt;
> 
> inline pt f(pt _p)
> {
>   long p = _p.p;
> 
>   return (pt) { (p) };
> }
> 
> static int mmap_mem(void)
> {
>   pt p;
>   p = f(p);
> 
>   return 0;
> }
> 
> *** ice.c ***
> 
> "gcc ice.c" gives an ICE on i386, ia-64 and x86-64 (at least) and prevents 
> kernel, glibc and X compilation. Remove the inline keyword and it does fine.
> 
> I have been hunting for the exact patch that started this, but you came with 
> this so I thought I would ask.

Well, seeing there a compound literal, my bet is this started with the
compound literal patch...

	Jakub

Re: inlining default

[Joe Buck]

> It seems that Neil's 2001-11-15 changes to option parsing had a side effect
> of turning on tree inlining at -O0 for C and C++ unless suppressed with
> -fno-inline, because we now set flag_tree_inline from flag_no_inline before
> setting flag_no_inline from optimize.  Is this what we want?

Probably not, because I'll bet that most people who say -O0 or who give
no -O switch at all are turning on -g, and inlining can make debugging
harder.

Re: inlining default

[Mark Mitchell]

--On Wednesday, December 12, 2001 02:00:03 PM +0000 Jason Merrill 
<jason@redhat.com> wrote:

> It seems that Neil's 2001-11-15 changes to option parsing had a side
> effect of turning on tree inlining at -O0 for C and C++ unless suppressed
> with -fno-inline, because we now set flag_tree_inline from flag_no_inline
> before setting flag_no_inline from optimize.  Is this what we want?  I
> would prefer to leave it off by default with -O0, but many compilers turn
> it on unless specifically disabled.  What do other people think?

I think we should leave it off at -O0.  I can't see a compelling
reason to change our historical practice.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: inlining default

[David Edelsohn]

>>>>> Mark Mitchell writes:

>> It seems that Neil's 2001-11-15 changes to option parsing had a side
>> effect of turning on tree inlining at -O0 for C and C++ unless suppressed
>> with -fno-inline, because we now set flag_tree_inline from flag_no_inline
>> before setting flag_no_inline from optimize.  Is this what we want?  I
>> would prefer to leave it off by default with -O0, but many compilers turn
>> it on unless specifically disabled.  What do other people think?

Mark> I think we should leave it off at -O0.  I can't see a compelling
Mark> reason to change our historical practice.

	Without inlining a -O0, GCC fundamentally uses a different source
stream with and without optimization.  This makes debugging at -O0 more
difficult. 

David

Re: inlining default

[Mark Mitchell]

> Mark> I think we should leave it off at -O0.  I can't see a compelling
> Mark> reason to change our historical practice.
>
> 	Without inlining a -O0, GCC fundamentally uses a different source
> stream with and without optimization.  This makes debugging at -O0 more
> difficult.

By one measure.

By not inlining at -O0, the code will behave as it is written; when
you get to a function call, you will tidily step into it, and so
forth it.  When we inline, in practice, we mess up the debugging
information enough that the user will see odd things in the debugger.

So, if there is a logic bug in the user's program, that will make
things harder to find.

Having some mode, called whatever you like, that does the most
naive translation from source to object conceivable is useful.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: inlining default

[Joe Buck]

> >> It seems that Neil's 2001-11-15 changes to option parsing had a side
> >> effect of turning on tree inlining at -O0 for C and C++ unless suppressed
> >> with -fno-inline, because we now set flag_tree_inline from flag_no_inline
> >> before setting flag_no_inline from optimize.  Is this what we want?  I
> >> would prefer to leave it off by default with -O0, but many compilers turn
> >> it on unless specifically disabled.  What do other people think?
> 
> Mark> I think we should leave it off at -O0.  I can't see a compelling
> Mark> reason to change our historical practice.

David Edelsohn writes:

> 	Without inlining a -O0, GCC fundamentally uses a different source
> stream with and without optimization.  This makes debugging at -O0 more
> difficult. 

David, I've been debugging g++-emitted code for about 11 years now, and
it feels quite natural to me.  I'd be irritated if the default changed,
as every Makefile I have would need to be changed.  Debugging is much more
difficult if the functions specified inline are inlined.

However, now that inlining is possible at -O0, you have the option of
specifying a flag to make it happen.  But what's important is that we
should not ask the users to change their Makefiles to avoid a change in
behavior that many would find undesirable.