similar to: Return on nocapture pointer

Thanks guys. Do you it make sense to extend the definition in LangRef? If so I will be happy to upload a patch. Piotr 2017-04-28 17:58 GMT+02:00 Hal Finkel <hfinkel at anl.gov>: > > > On 04/28/2017 10:22 AM, Piotr Padlewski via llvm-dev wrote: > > Hi, > I have a question about semantics of nocapture attribute: > "This indicates that the callee does not make any

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: >>

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 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

> Please review the 2.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

Hi All, Please review the 2.5 release notes here: http://llvm.org/docs/ReleaseNotes.html Let me know if you have any additions, improvements, or see any oversights. If you have commit access, please just directly change the document. The release is planned to go out in about 24 hours from now! Thanks! -Chris

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

Hey all, I was doing some investigation of LICM and I ran into something that seems a bit odd to me. Suppose I was looking at the following code snippet: #define N 1000 int main() { int B[N]; char A[N]; for(int i=0; i<N; i++) { B[i] = strlen(A); } return B[0]+B[N-1]; } Among other optimizations that I may want to happen, I'd hope that the call to strlen could be

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 >

After I spend some time working with the function attribute* deduction pass** [1,3], I would like to propose a "proper" organization***. Why? Because we do not derive nearly as many attributes as we could****, while we do maintain various (separate and diffently organized) "data-flow-like analyses" to do so. What else? I propose a single optimistic data-flow

I am writing a small ruby script that will be accepting input from postfix''s pipe command (ie, not running via the shell, directly executing). One of the things I need to do it spec the exit codes to make sure I am returing the correct exit codes for each condition as Postfix will then return SMTP errors as appropriate. I have two files that concern this bit of the program, init.rb and

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

Hi, My * refuses SIP registrations when internet is down. All is returing at the moment when outside connection is up. What is wrong? -- Best regards, Michael Strelnikov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060410/35bd0b15/attachment.htm

It seems that the system() and system2() functions don't close file descriptors between the fork() and exec() (on Unix platforms, of course). This means that the child processes inherit open files and socket connections. Running this (from a terminal) will result in the child process writing to a file that was opened by R: R f <- file('foo.txt', 'w') system('echo

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:

On Thu, Jul 04, 2019 at 12:17:48PM -0700, Chia-I Wu wrote: > On Thu, Jul 4, 2019 at 4:10 AM Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > Hi, > > > > > > - r = ttm_bo_reserve(&bo->tbo, true, false, NULL); > > > > + r = reservation_object_lock_interruptible(bo->gem_base.resv, NULL); > > > Can you elaborate a