Re: what's required for builtin_memcpy to be inlined

[Artur Skawina <skawina at geocities dot com>]

Joe Buck wrote:
> 
> > ..other than constant size argument?
> 
> Actually, it's platform-dependent.  Presumably you have ia32 hardware.

yes, forgot to mention that.

> > i used to have memcpy defined as
> >
> > #define memcpy(t, f, n) \
> > (__builtin_constant_p(n) ? \
> >  __builtin_memcpy((t),(f),(n)) : \
> >  __memcpy((t),(f),(n)))
> >
> > but this is apparently not enough, as it breaks for this construct
> > (from linux-2.3.17/fs/udf/namei.c):
> >
> > >             len = sizeof(struct FileIdentDesc);
> > >
> > >             if (len <= offset)
> > >                     memcpy((Uint8 *)sfi, (Uint8 *)cfi, len);
> 
> __builtin_constant_p(len) is false here.

are you saying it _should_ be false?
It is _true_, which actually surprised me as i've seen it return false
for very similar code... As 'len' is obviously constant when memcpy is
called i think it is right returning true, and it's the builtin
falling back to the (nonexistent) lib version that's the real problem.
Note that the compiler generates a 'pushl  $0x26' when calling memcpy
so i just don't see why it chooses to not inline..


> You could try
> 
> #define LEN_FILEIDENT sizeof(struct FileIdentDesc)
> 
>         if (LEN_FILEIDENT <= offset)
>         memcpy((Uint8 *)sfi, (Uint8 *)cfi, LEN_FILEIDENT);

Once the problem is identified, the workaround is obvious, yes.
But i'd like to avoid doing it this way because it makes the
code less readable (though this matters more in other places than here,
and there i usually had the opposite problem -- expressions are
not recognized as constant even when that's clearly the case).