[LLVMdev] Clang question

[Ryan Taylor]

As a command line argument for clang? Or an opt? Says, "argument unused
during compilation", but I think that is basically what I'm looking for
right?

On Mon, Mar 5, 2012 at 1:44 PM, Owen Anderson <resistor at mac.com> wrote:

> Does -fno-builtin[-memcpy] handle this?
>
> --Owen
>
> On Mar 5, 2012, at 12:35 PM, Eric Christopher wrote:
>
> > You'll need to do the work then. I'd also question why? On most
> platforms a decent memcpy exists.
> >
> > -eric
> >
> > On Mar 5, 2012, at 12:28 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> >
> >> I would like it to always be lowered, I don't want it.
> >>
> >> On Mon, Mar 5, 2012 at 12:27 PM, Eric Christopher <echristo at apple.com>
> wrote:
> >> You don't have memcpy or want it to always lower it?
> >>
> >> -eric
> >>
> >> On Mar 5, 2012, at 11:56 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> >>
> >>> Christoph,
> >>>
> >>> Yes, you are correct on the lifetime calls, they are just markers for
> liveness.
> >>>
> >>> However, the backend is not optimizing these calls away. I could try
> to deal with them outside of llvm but I was hoping for a cleaner solution
> using llvm?
> >>>
> >>> On Mon, Mar 5, 2012 at 11:51 AM, Christoph Erhardt <
> christoph at sicherha.de> wrote:
> >>> Hi Ryan,
> >>>
> >>> the compiler is free to insert implicit calls to memcpy(), for instance
> >>> for assignments from one struct/class variable to another. The same
> goes
> >>> for memset(), which may be inserted implicitly for the initialization
> of
> >>> local structs or arrays.
> >>>
> >>> The good news is that the backend normally optimizes these calls away
> >>> where possible, replacing them with simple moves - at least as long as
> >>> the number of bytes to copy does not exceed a certain threshold.
> >>>
> >>> As for the llvm.lifetime intrinsics, take a look at the documentation:
> >>> http://llvm.org/docs/LangRef.html#int_memorymarkers
> >>> If I'm not mistaken, these calls seem to be used to mark the lifespan
> of
> >>> a stack-allocated object.
> >>>
> >>> Regards,
> >>> Christoph
> >>>
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120305/4a9c4d12/attachment.html>