This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC Patch]: Implement remainder() as built-in function [PR fortran/24518]


Hi Mike,

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
		ret

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.

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]