Re: HORRIBLE inliner defaillance

[Roger Sayle <roger at eyesopen dot com>]

On 27 Oct 2003, Gabriel Dos Reis wrote:
> Benjamin Kosnik <bkoz@redhat.com> writes:
>
> | >following up to Jerry heads up of a while ago
> | >(http://gcc.gnu.org/ml/libstdc++/2003-02/msg00056.html) I really
> | >would like to have some feedback from the compiler people about
> | >this horrible thing.
> |
> | See:
> | http://gcc.gnu.org/ml/libstdc++/2003-02/msg00302.html
> | (This is what should be linked in the TODO, sorry)
>
> Yes, this is the third time I'm seeing pointers to that message and
> I'll repeat what I've said a second time: It does nto work.  As RTH
> said, it is a problem with the inliner.  Random "const" will not fix
> it. The reason is that toplevel "const" get lost very quickly.

Gaby is correct, the real problem is that inlining doesn't propagate
the fact that the size argument to memcpy is const by the time we
reach RTL expansion, so expand_builtin_memcpy can't see any benefit
over calling the optimized glibc routine. For x86, glibc's memcpy
has many special case implementations for memcpy, so its fast but
much too big to inline.  Hence the i386 calls it unless it can see
some "specialization" at compile-time (RTL expansion time).

On x86 there's a minor improvement from using -minline-all-stringops,
but without alignment or size information during expansion, the result
is still poorer than calling __builtin_memcpy directly.

Hopefully, this will be magically resolved in tree-ssa.  Alternatively,
it may be possible to teach the middle-end about the semantics of the
memcpy libcall, and try re-expanding it using movstr* should constants
get propagated into it's argument list during the RTL optimizers.

Just some thoughts.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833