search for: outlives

Hi all, Is there a function attribute or otherwise way to query whether a function could write to memory that outlives itself? For example writing to a global or memory passed in via a function argument would be writing to memory that outlives the function, but writing to a stack variable or allocation that isn't returned would not. Cheers, Billy Moses -------------- next part -------------- An HTML attachmen...

Hi, I have a question about semantics of nocapture attribute: "This indicates that the callee does not make any copies of the pointer that outlive the callee itself. " Is returing a pointer considered outliving callee? For example is this code valid: define i8* @foo(i8* nocapture %p) ret i8* %p } The documentation also mention that " This is not a valid attribute for return

...es that the callee does not make any copies of the pointer > that outlive the callee itself. " > Is returing a pointer considered outliving callee? For example is this > code valid: > > > Yes, it includes returning the pointer. The code below is invalid. The > return value outlives the callee itself. > > > define i8* @foo(i8* nocapture %p) > ret i8* %p > } > > The documentation also mention that " This is not a valid attribute for > return values.", but I interpret that it is is about this case: > > declare i8* nocapture @bar(i8* %p)...

Regarding the nocapture attribute the language ref says: "the callee does not make any copies of the pointer that outlive the callee itself". >From I inferred that it is OK for the callee to make a copy of the pointer that doesn't outlive the call. However if I write some code that does this the optimizers don't do what I'd expect. Consider the following the example:

Hi Richard, I think it is a bug. Ciao, Duncan. On 08/10/12 14:34, Richard Osborne wrote: > Regarding the nocapture attribute the language ref says: "the callee does not > make any copies of the pointer that outlive the callee itself". From I inferred > that it is OK for the callee to make a copy of the pointer that doesn't outlive > the call. However if I write some

Is this code valid? Function f takes a "nocapture" pointer p, and passes it to function g that does not have nocapture in its parameter list. There is nothing to stop g from "capturing" p. -Krzysztof On 10/8/2012 8:54 AM, Duncan Sands wrote: > Hi Richard, I think it is a bug. > > Ciao, Duncan. > > On 08/10/12 14:34, Richard Osborne wrote: >>

Hello, Attached is the proposal that I have submitted. I would be grateful for any and all feedback provided. Many Thanks, Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: GSoc Proposal 2016 - Scott Egerton.pdf Type: application/pdf Size: 391088 bytes Desc: GSoc Proposal 2016 - Scott Egerton.pdf URL:

I'm running Fedora14 on all machines, including my wife's -- and I'm the nearest (distant) thing there is to tech support. She's far more likely to outlive me than I her; so I want to install something requiring a lot less maintenance on her machine, so that she'll have it and be used to it, years ahead of need. I'm thinking CentOS 6, whenever it's ready, is

Today, rsyncd manages its pid file by open()ing it with O_CREAT|O_EXCL at startup, and then unlink()ing it at shutdown. If the open() fails at startup because the file already exists, then rsyncd will assume another instance of itself is already running and not start. However, there's a problem with this approach: if rsyncd is terminated without being able to clean up (e.g., kill -9, or the

...5 release notes here: http://llvm.org/docs/ReleaseNotes.html The description of nocapture is a bit funny: "... pointer arguments to functions that access through but do not return the pointer in a data structure that out lives the call" I think it needs s/return/retain/ and s/out lives/outlives/ > In addition, many APIs have changed in this release. Some of the major LLVM API changes are: The ones I encountered were: - The syntax of Intrinsics*.td changed in an incompatible way; Intrinsic<[llvm_i32_ty, llvm_ptr_ty, llvm_ptr_ty]> used to mean the return type was i32 and the par...

Hi all, Are you sure that the problem here is with the nocapture flag and not with the noalias? Removing noalias from the function definition of @f results in the expected output. My guess is that something goes wrong in determining that *%q can be based on %p through @g which results in a 'no alias' relation for the two where there should be a 'may alias' result. For

hi all, I've written a small language implementation that JIT-compiles code prior to execution. At the moment, i execute the function through ExecutionEngine::runFunction. However, this requires me to keep all of the code generation artifacts (instructions, constants, etc) around during execution. Given that execution compiles the program down to machine code, is there a reasonably

Hi Krzysztof, > Is this code valid? yes, I think so. > Function f takes a "nocapture" pointer p, and passes it to function g that does > not have nocapture in its parameter list. There is nothing to stop g from > "capturing" p. It would be wrong for the optimizers to deduce a nocapture attribute for f in this context, as they don't know anything about the

Hi, > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > Can you elaborate a bit about how TTM keeps the BOs alive in, for > example, virtio_gpu_transfer_from_host_ioctl? In that function, only > three TTM functions are called: ttm_bo_reserve, ttm_bo_validate, and >

Hi, > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > Can you elaborate a bit about how TTM keeps the BOs alive in, for > example, virtio_gpu_transfer_from_host_ioctl? In that function, only > three TTM functions are called: ttm_bo_reserve, ttm_bo_validate, and >

Hello, I've set-uped a Linux server in a small office, around 10 users, there is an old novel server, running version 3.12. My task was to establish an alternative for the old server, for the case It suddenly didn't feel like working anymore (you see, it's a Pentium Pro 200, it outlived itself at least a few times over). So basically, everybody have access to it using IPX (

Den 07.02.2020 09.41, skrev Thomas Zimmermann: > The simple-encoder helpers initialize an encoder with an empty > implementation. This covers the requirements of most of the existing > DRM drivers. A call to drm_simple_encoder_create() allocates and > initializes an encoder instance, a call to drm_simple_encoder_init() > initializes a pre-allocated instance. > >

...al: lsof -c R -c sleep it will show that both the R and sleep processes have the file open: ... R 324 root 3w REG 0,48 0 4259 /foo.txt ... sleep 327 root 3w REG 0,48 0 4259 /foo.txt This behavior can cause problems if R spawns a child process that outlives the R process, but keeps open some resources. Would it be possible to add an option to close file descriptors for child processes? It would be nice if that were the default, but I suspect that making that change would break a lot of existing code. To take an example from the Python world, subproc...

...o_validate, and > > > ttm_bo_unreserve. I am curious how they keep the BO alive. > > > > It can't go away between reserve and unreserve, and I think it also > > can't be evicted then. Havn't checked how ttm implements that. > Hm, but the vbuf using the BO outlives the reserve/unreserve section. > The NO_EVICT flag applies only when the BO is still alive. Someone > needs to hold a reference to the BO to keep it alive, otherwise the BO > can go away before the vbuf is retired. Note that patches 14+15 rework virtio_gpu_transfer_*_ioctl to keep gem re...

On Mon, 2011-03-07 at 15:05 -0700, Joshua Warner wrote: > I actually meant uncommon in the sense of having stack-allocated > unions that participate in garbage collection. Off the top of my > head, I could only name one language (ML) that might use a feature > like that. Even then, I suspect most ML implementations would > actually push that stuff onto the heap. Common Lisp has