llvm dev - Oct 2016 - How to remove memcpy

Even with -ffreestanding LLVM generates memcpy/memset? Does this mean some
passes do not honor this flag? If you really wanted to prevent libcalls,
you could technically translate those memcpy/memset to loops in lowering.
Kevin

On Sat, Oct 15, 2016 at 4:10 PM, Wolfgang McSneed via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Mehdi and Joerg,
>
> Thanks for your fast response! attached is the matrix_float.c file.
>
> Also - I should point out that I am using MIPS ISS.
>
> Thanks,
>
> Wolf
>
> Kind Regards,
>
> Wolf
>
> On Sat, Oct 15, 2016 at 6:07 PM, Joerg Sonnenberger via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Sat, Oct 15, 2016 at 04:01:36PM -0700, Mehdi Amini via llvm-dev
wrote:
>> >
>> > > On Oct 15, 2016, at 3:56 PM, Wolfgang McSneed via llvm-dev
<
>> llvm-dev at lists.llvm.org> wrote:
>> > >
>> > > Hi,
>> > >
>> > > I am hoping that someone can help me figure out how to
prevent the
>> insertion of "memcpy" from the assembly source.
>> > >
>> > > My target is an instruction set simulator that doesn't
support this.
>> > >
>> > > Thank you for your valuable time.
>> > >
>> > > Wolf
>> > >
>> > > Here are my compile commands:
>> > > $ clang -emit-llvm -fno-builtin -o3 --target=mips -S
matrix_float.c
>> -o vl_matrix_float.ll
>> >
>> > Technically  -fno-bultin prevents the compiler from understand the
>> > memset in the original code. The right option to prevent the
compiler
>> > from insert libc calls “out-of-the-blue” is -ffreestanding.
>>
>> Huh? The -fno-builtin is not the problem. The compiler is *expected* to
>> call certain functions even for -ffreestanding. memcpy and memset are
>> two of those. It is certainly perfectly valid target lowering for
>> llvm.memcpy to be turned back into a libcall.
>>
>> Joerg
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161015/6f08e2c1/attachment.html>

On Sat, Oct 15, 2016 at 04:12:15PM -0700, Flamedoge
wrote:
> Even with -ffreestanding LLVM generates memcpy/memset? Does this mean some
> passes do not honor this flag? If you really wanted to prevent libcalls,
> you could technically translate those memcpy/memset to loops in lowering.
> Kevin
Yes, LLVM follows the same rules as GCC here:

  GCC requires the freestanding environment provide `memcpy', `memmove',
  `memset' and `memcmp'.

As I said, target lowering may decide to inline all the llvm.mem*
intrinsics, but it is typically wasteful to do so. Exceptions are e.g.
on x86 when optimising for size, since the function call overhead is
large than the "rep stosb" sequence would be for memset or "rep
movsb"
or memcpy.

Joerg

Also - I tried both -fno-builtin and  -ffreestanding and code with memcpy
was still produced.



Kind Regards,

Wolf

On Sat, Oct 15, 2016 at 6:17 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Sat, Oct 15, 2016 at 04:12:15PM -0700, Flamedoge wrote:
> > Even with -ffreestanding LLVM generates memcpy/memset? Does this mean
> some
> > passes do not honor this flag? If you really wanted to prevent
libcalls,
> > you could technically translate those memcpy/memset to loops in
lowering.
> > Kevin
>
> Yes, LLVM follows the same rules as GCC here:
>
>   GCC requires the freestanding environment provide `memcpy',
`memmove',
>   `memset' and `memcmp'.
>
> As I said, target lowering may decide to inline all the llvm.mem*
> intrinsics, but it is typically wasteful to do so. Exceptions are e.g.
> on x86 when optimising for size, since the function call overhead is
> large than the "rep stosb" sequence would be for memset or
"rep movsb"
> or memcpy.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161015/e279ca7c/attachment.html>