This is the mail archive of the gcc@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]

Re: builtin standard functions


> > - If no suitable assembler instruction can be found
> 
> This is ia32, the instruction(s) are at hand.

This is not what I meant. In the machine description (e.g. i386.md),
each pattern might be constrained by some condition. If no instruction
can be found where the constraints are met, inline-expanding will
fail, and the library function is called. If you look at the definition

(define_expand "movstrsi" ...

you'll see the constraint

  if (GET_CODE (operands[2]) != CONST_INT)
    FAIL;

which means that the string move pattern is only used for known
size_t.

> memset(a, 117, sizeof(a)) generates a library call in the following
> example with egcs-19990524 -O2 -fomit-frame-pointer -march=pentium:

I'd generally recommend to spell-out the builtin function names if you
expect the compiler to use the inline version. This will bypass any
optimization options, and in general tell the compiler to absolutely
consider inlining. If it then still doesn't, it's either a bug, or a
(hopefully documented) limitation.

>    memset(a, 117, sizeof(a));

I see. It seems that memset is only inlined if the argument is 0, so
this is really bzero. That is quite hard-wired into the middle-end;
it calls clear_storage once it is convinced that the argument are OK.

There is currently no generalization of that functionality in gcc.
It probably would be possible to extend this in the way that the Linux
memset works, but it seems that it is currently not supported.

For a 32-bit machine, the inherent problem is that you want to do
word-based clear instructions, which are easy if you know that you are
writing zeroes. If you are writing (byte)117, you have to come up with
a word that has the same bit pattern, using the multiplication
0x01010101*117.


>    r += strcmp(a, b);

This is not inlined because neither argument has a known size.

> I assume the original kludge around mem*, str* in the kernel was
> exactly because of this kind of concern (the builtins are still
> (after years, AFAIKS) marked "experimental" in gcc/c-decl.c, BTW).

The builtins have very clear restrictions; and most of those are
documented in expr.c:expand_builtin.

Of course, if the Linux kernel starts using and requiring them, I'd
expect that the missing wholes would be closed sooner or later, and
that they'll lose their experimental status. I don't think they ever
generate *wrong* code; and if they would, fixing that would probably
high-priority.

Regards,
Martin


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