Re: Optimizations on long long multiply/divide on PowerPC32 don't

Re: Optimizations on long long multiply/divide on PowerPC32 don't

[dewar]

<<If I understand correctly, Inline_Always not inlining at -O0 is
considered a bug. Any available test case or description for the
subtle issues you mention?
>>

Yes, we consider that a bug

Re: Optimizations on long long multiply/divide on PowerPC32 don't work

[Linus Torvalds]

On Mon, 10 Dec 2001, Paul Koning wrote:
>
>  Linus> ...Not linking against libgcc has found several problems in gcc.
>  Linus> Ranging from missing totally obvious optimizations...
>
> Does that mean that Linux isn't expected to build if you disable
> optimization?  That seems strange, considering that debugging with gdb
> is often easier with -O0.

Linux has always required optimizations to build. Since day 1, in fact.

That is partly because I just cannot ever imagine running the code that
gcc outputs without optimizations, but even more because gcc functionality
at -O0 is seriously lacking:

Gcc doesn't support inline functions without optimization (it does in C++,
and it may be that even the C side has started to honour the "inline"
keyword, but I've never been interested enough to check), and Linux has
always tended to prefer inline functions over complicated macros.

I never made "backing" static functions for things like "inb/outb" etc,
that actually expand in the end to just one assembler function.

And I don't know about you, but I debug almost exclusively on a source
level (where compiler optimizations do not matter) or, when I have to, on
an assembler level (where the code is actually _more_ readable with
optimizations). So I'd never use -O0 anyway.

			Linus

Re: Optimizations on long long multiply/divide on PowerPC32 don't

[Joe Buck]

Linus writes:
> Gcc doesn't support inline functions without optimization (it does in C++,
> and it may be that even the C side has started to honour the "inline"
> keyword, but I've never been interested enough to check), and Linux has
> always tended to prefer inline functions over complicated macros.

No, even in C++ GCC does not inline functions without optimization.

Re: Optimizations on long long multiply/divide on PowerPC32 don't

[guerby]

> No, even in C++ GCC does not inline functions without optimization.

Same thing for Ada, although a GNAT specific pragma named
Inline_Always exists, my reading of gigi code implies that it still
requires optimizations to be active for the inlining to occur:

gcc/ada/trans.c
<<
static void
process_inlined_subprograms (gnat_node)
     Node_Id gnat_node;
{
  Entity_Id gnat_entity;
  Node_Id gnat_body;

  /* If we can inline, generate RTL for all the inlined subprograms.
     Define the entity first so we set DECL_EXTERNAL.  */
  if (optimize > 0 && ! flag_no_inline)
>>

gcc/ada/gnat_rm.texi
<<
@findex Inline_Always
@item pragma Inline_Always
@noindent
Syntax:

@smallexample
pragma Inline_Always (NAME [, NAME]);
@end smallexample

@noindent
Similar to pragma  @code{Inline} except that inlining is not subject to
the use of option @code{-gnatn} for inter-unit inlining.
>>

Should I provide a patch to mention explicitely that optimization
needs to be on for inlining to occur with Inline_Always?

-- 
Laurent Guerby <guerby@acm.org>

Re: Optimizations on long long multiply/divide on PowerPC32 don't

[Arnaud Charlet]

> Same thing for Ada, although a GNAT specific pragma named
> Inline_Always exists, my reading of gigi code implies that it still
> requires optimizations to be active for the inlining to occur:

The front end inlining mechanism is supposed to take care of this. but
there are still some subtle issues that prevent it from working properly.

Anyway, the documentation should not be fixed, since the intent is definitely
to always inline.

Arno

Re: Optimizations on long long multiply/divide on PowerPC32 don't

[guerby]

> The front end inlining mechanism is supposed to take care of this. but
> there are still some subtle issues that prevent it from working properly.
> Anyway, the documentation should not be fixed, since the intent is definitely
> to always inline.

If I understand correctly, Inline_Always not inlining at -O0 is
considered a bug. Any available test case or description for the
subtle issues you mention?

-- 
Laurent Guerby <guerby@acm.org>