similar to: [LLVMdev] byval and copy constructors / destructors.

On Friday 28 November 2014 14:44:30 Richard W.M. Jones wrote: > [NOTE: this is not the complete patch. Once ACKed, I will make the > same mechanical change to all the other places in the library that use > this pattern.] > --- > src/guestfs-internal.h | 24 ++++++++ > src/inspect-fs-unix.c | 164 +++++++++++-------------------------------------- > 2 files changed, 59

[NOTE: this is not the complete patch. Once ACKed, I will make the same mechanical change to all the other places in the library that use this pattern.] --- src/guestfs-internal.h | 24 ++++++++ src/inspect-fs-unix.c | 164 +++++++++++-------------------------------------- 2 files changed, 59 insertions(+), 129 deletions(-) diff --git a/src/guestfs-internal.h b/src/guestfs-internal.h index

Hi Tim, Correction to my last email. What I should have said is that the new pointer is used by the callee rather than the original byVal pointer arg. (the byVal pointer arg remains but is not used by the callee). viz: define void @f1(%struct.tag* byval) { entry: %st = alloca %struct.tag, align 4 %1 = bitcast %struct.tag* %st to i8* %2 = bitcast %struct.tag* %0 to i8* call void

Hi Robert, suppose you have a "byval" argument with type T*, and the caller passes a T* called %X for it, while in the callee the argument is called %Y. The IR level semantics are: (1) a copy should be made of *%X. Whether the callee or the caller makes the copy depends on the platform ABI. (2) in the callee, %Y refers to the address of this copy. There are many ways (1) can be

Hi Tim, I may be missing something but using CCPassByVal is moving the pointer onto the stack - not what I'm after. I need to add an operation to the function prolog that actually makes a copy of the pointed to data. It is the responsibility of the callee to make the copy, not the caller - hence my trouble. (currently the callee can corrupt the original data viz pass-by-reference!) This

Hi - help! I have read through previous threads on the subject of 'byval' e.g. https://groups.google.com/forum/#!topicsearchin/llvm-dev/Exact$20meaning$20of$20byval/llvm-dev/cyRZyXcMCNI https://groups.google.com/forum/#!topicsearchin/llvm-dev/$20byval/llvm-dev/uk4uiK93jeM https://groups.google.com/forum/#!topicsearchin/llvm-dev/byval/llvm-dev/46Tv0lSRwBg and read through code

Hi, > I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. >From very quick test-cases with no understanding of XCore, that looks plausible. > LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). > This is where I placed the CCIfByVal<CCPassByVal<0,4>>

Hi Tim, Thought about it last night and was coming to the same conclusion. 1. it cant be done at the end during lowering (target backend). 2. it should be part of llvm as the byVal needs to be handled. As a twist, I have been told that llvm-gcc can lower byVal into memcpy in the callee. I may take a look at this. I wonder if it ever emits 'byVal'... I still feel I don't understand

Hi Robert, > This should ideally be done early on in the IR in my thinking - to allow optimisation if the data is only ever read. I've thought that once or twice when dealing with ABIs myself. That's certainly another possibility in your case. You could create a separate FunctionPass that gets executed early on and replaces all byval calls and functions with the correct memcpys. It

Heyho, Recently I tried out the ORCv2 JIT, especially the LLJIT. I gotta say, that I really like the new interface and the way you use it! However there is one thing I'm missing. I wrote a small bit code file, which should force having a global constructor. int wuff(); __declspec(noinline) int miau() { printf("Huhuhu"); return wuff(); } const int x = miau(); When I

Hi Tim, Thank you for the input. I think I follow you. I believe the LowerCall is doing what it needs to do - passing pointer either on the stack or in register as per ABI. The LowerFormalArguments() is where I am stuck. LowerFormalArguments () calls CCInfo.AnalyzeFormalArguments(Ins, CC_XCore), which calls the CC_XCore(). This is where I placed the CCIfByVal<CCPassByVal<0,4>> which

Hi Robert, > I tried adding to the XCoreCallingConv.td: > CCIfByVal<CCPassByVal<0,4>> // pushes pointer to the stack This looks sensible to me. After that it comes down to cooperation between XCoreISelLowering's LowerFormalArguments and LowerCall functions. LowerFormalArguments is at the beginning of a function and is responsible for taking arguments out of

On Fri, Sep 9, 2011 at 1:36 PM, Graham Wakefield <wakefield at mat.ucsb.edu> wrote: > Hi there, > > I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. > > I don't know if this is an LLVM or Clang issue, from looking at the IR (see

The following series makes use of the skb fragment API (which is in 3.2 +) to add a per-paged-fragment destructor callback. This can be used by creators of skbs who are interested in the lifecycle of the pages included in that skb after they have handed it off to the network stack. The mail at [0] contains some more background and rationale but basically the completed series will allow entities

Óscar Fuentes <ofv at wanadoo.es> writes: > Michael Spencer <bigcheesegs at gmail.com> writes: > > The problem is that MSVC++ requires sprinkling > > __declspec(dllexport/dllimport) all over the code, and we really don't > > want to deal with maintaining that, as most developers have little to > > no experience with Windows DLLs. > > BTW, you

On Mar 28, 2013, at 1:35 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: Oscar, just FYI, your wording is very strong, and that is often not the most productive way to make your point. That said, to address some of the things you've raised in a couple of threads: >> If you think these are irrelevant points then you need to state why >> and should back it up with less

Óscar Fuentes <ofv at wanadoo.es> writes: >> It appears the Windows build has regressed over the past week. >> >> The build fails quite early (during the "Performing TableGenStep" >> phase). >> >> Any help/pointers would be appreciated. > > It breaks for me because the usage of INT64_C, which was introduced on > r57663 and 57668. >

Has anyone figured out how to create a destructor in R.oo? How I'd like to use it: I have an object which opens a connection thru RODBC (held as a private member) It would be nice if the connection closes automatically (inside the destructor) when an object gets gc()'ed. Thanks in advance. Regards, Ken BTW, a >BIG< thanks to Henrik Bengtsson for creating the R.oo package! Lucky

Hi there, I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. I don't know if this is an LLVM or Clang issue, from looking at the IR (see below) it looks like the destructor is being tied to cxa_atexit, and I wonder if that is not called by

a static local still produces a static dtor, though One of the ways you can get around this is with a deliberate non-cleanup: const foo &getFoo() { static const foo &f = *new foo(); return f; } that way no global dtor runs. Obviously only works if you don't need foo's dtor to run. On Tue, Mar 8, 2016 at 11:42 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org>