std::pow implementation
Steven Bosscher
s.bosscher@student.tudelft.nl
Wed Jul 30 13:26:00 GMT 2003
Op wo 30-07-2003, om 14:22 schreef Richard Guenther:
> On 30 Jul 2003, Gabriel Dos Reis wrote:
>
> > Richard Guenther <rguenth@tat.physik.uni-tuebingen.de> writes:
> >
> > | Of course being able to hint the compiler some more can be useful to
> > | overcome weakness in the compilers inlining decision implementation as
> > | that never will be perfect.
> >
> > It takes first abandoning the idea that the compiler always knows
> > better than the programmer and the programmer's use of "inline" is
> > most of the time nonsensical. The programmer does provide hint. The
> > compiler choses not to listen.
>
> Well, the point is you question that inline should be a hint, but take it
> as the same as __attribute__((always_inline)) is defined. The compiler is
> free to ignore hints if it thinks the hint is against the task it is
> performing (take f.i. a inline declared modestly sized function when
> compiling with -Os).
No, always_inline also implies inlining functions that call alloca, so
it's a bit stronger than that.
The attached patch makes C++ ignore inline limits if the function was
declared with "inline". Maybe you can try and see what it does for you?
> I'd argue for the inline keyword makeing the compiler think twice before
> not inlining a function and -finline-functions on by default (if inline is
> a hint to inline, why should no inline force the compiler not to inline?).
That could be done by setting max-inline-insns-single to a larger value
for C++. This has been discussed many times and your numbers show it
would help, but at an unacceptable cost of compiler speed. IIRC a lot
of the slowdown was in expand, so with tree-ssa we could give this
another try (assuming tree-inline can clean up a lot of cruft before
expanding...).
Gr.
Steven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inline_patch.diff
Type: text/x-patch
Size: 1539 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20030730/95e9c58f/attachment.bin>
More information about the Gcc
mailing list