This is the mail archive of the
mailing list for the GCC project.
Re: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: "Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>, Richard Guenther <richard dot guenther at gmail dot com>, Uros Bizjak <ubizjak at gmail dot com>, FX Coudert <fxcoudert at gmail dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 25 Oct 2006 13:49:15 -0600 (MDT)
- Subject: Re: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]
On Wed, 25 Oct 2006, Mike Stump wrote:
> On Oct 25, 2006, at 6:42 AM, Kaveh R. GHAZI wrote:
> > I agree with Richard that transforming printf("hello") into
> > fputs("hello",__get_stdout()) may not be a good option.
> For -Os, that would be bad. For -O2, I'd let the numbers speak for
> themselves, though, I'd also tend to think it might not be worth it.
My first thought was to argue that a __get_stdout function should be
a very fast subroutine call. It doesn't need to set up a stack frame,
doesn't have any arguments, does it's decode magic and places the
result in a register. Often, it something as simple as
__get_stdout: mov %eax, __stdout
or similar. This is compounded by the fact that we can mark the
function as "const", and CSE and re-use this pointer in the caller.
With call prediction and target buffers, etc.. the cost of a lightweight
libcall is likely to be cheaper than the saved cycles between printf
and fputs or fwrite (for example).
However, it then occured to me that we can be even cleverer still:
extern FILE *__libgcc_stdout = stdout;
We can completely avoid the function call. Our issue is that libc's
stdout isn't guaranteed to be mapped to a single simple symbol, and
is often #defined to something cryptic. libgcc can avoid this by
declaring the required stable symbol itself. Hence, in generated
code we can simply refer to "__libgcc_stdout".
Unless I'm missing something.