similar to: [LLVMdev] Meaning of the nocapture attribute (possible bug?)

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

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

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

someguy wrote: > Hi All, > > I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; > mov rX,0; END:" sequence. > > Chris mentioned that the PPC code (as well as the x86 SSE code) does > this, but I can't seem to find it. > > What I really need to kmow is how to insert the branch/label pair at > instruction selection phase. > > Anyone

Hi All, I need to implement select_cc as a "cmp; mov rX,1; brcond cnd, END; mov rX,0; END:" sequence. Chris mentioned that the PPC code (as well as the x86 SSE code) does this, but I can't seem to find it. What I really need to kmow is how to insert the branch/label pair at instruction selection phase. Anyone have an example of this?

Thanks for reviewing this. Committed in r98255 and r98256. The bug against the ARM backend is 6581: http://llvm.org/bugs/show_bug.cgi?id=6581 On 10/03/10 21:45, Chris Lattner wrote: > Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! > > -Chris > > On Mar

Hi, I'm trying to get AA results for two pointers, but it seems that AA cannot look though a memcpy. For example: define dso_local spir_func void @fun() { entry: ; Store an address of `var' %var = alloca i32, align 4 store i32 42, i32* %var, align 4 %var.addr = alloca i32*, align 8 store i32* %var, i32** %var.addr, align 8 ; Memcpy

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>

Hello all. At XMOS we are working towards updating the upstream XCore backend for newer versions of the chip. XCore is the XMOS processor. The XCore backend was written by Richard Osborne at XMOS. Richard has moved on. The current code owner in CODE_OWNERS.TXT, Robert Lytton, has also moved on. For some years XMOS has developed the compiler in-house, for new versions of the chip, but not

It seems to me that emitting DWARF line number information using .loc directives is currently broken. CellSPU is currently the only in tree target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it to produce any line number information. Is this a known issue? I understand that there are lots of changes going on in this area. Any idea what it would take to fix? -- Richard

Typo "responisbility", otherwise looks great to me, please apply. For ARM, please just file a bugzilla suggesting that the ARM backend adopt this. Thanks Richard! -Chris On Mar 9, 2010, at 6:06 AM, Richard Osborne wrote: > On 02/03/10 00:11, Jim Grosbach wrote: >> On Mar 1, 2010, at 4:09 PM, Richard Osborne wrote: >> >>> On 01/03/10 21:14, Chris Lattner

If I give instcombine the following IR: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %c = getelementptr [1 x i8]* %a, i32 0, i32 0 %d = getelementptr [1 x i8]* %b, i32 0, i32 0 %cmp = icmp ult i8* %c, %d ret i1 %cmp } It optimizes it into: define i1 @f([1 x i8]* %a, [1 x i8]* %b) { %cmp = icmp slt [1 x i8]* %a, %b ret i1 %cmp } Is this a bug, or are there some semantics of icmp

With LLVM built from trunk I understand I should now use llvm-config --system-libs to get the system libraries to link against when linking against llvm (as of r197664). If run this then llvm-config outputs a blank line before the system libraries, for example on Linux I get: $ llvm-config --system-libs -lz -ltinfo -lrt -ldl -lm If I use --system-libs together with --libs the LLVM libraries

On 12/5/18 2:14 PM, Andrew Savonichev wrote: >> On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >>>> Hi, >>>> >>>> I'm trying to get AA results for two pointers, but it seems that AA >>>> cannot look though a memcpy. For example: >>>> >>>> define dso_local spir_func void @fun() { >>>>

Hi, I'm a compiler engineer at XMOS (http://www.xmos.com) and in the last few months I've been working on porting LLVM to target our XS1-G4 chip. I thought it may be of interest to the list to find out how we are using of LLVM. The XS1-G4 has four processors and 32 hardware threads. It has been designed to be highly responsive to I/O events allowing many tasks normally be done by

Chris Lattner wrote: > On Jan 14, 2009, at 3:14 AM, Richard Osborne wrote: > > >>> Evan >>> >> OK, that make sense, I'll take a look at changing this. I've added a >> bug >> for the issue: >> >> http://llvm.org/bugs/show_bug.cgi?id=3324 >> >> There is currently no Backend: XCore component in bugzilla so

Hi Richard, Thanks for working on this! Your patched solved my initial problem, but introduced another one. Please find attached another BC file that fails on xcore with the linear scan regalloc. This is the error message I get eliminateFrameIndex Frame size too big: -3 0 llc 0x08affd1e 1 libc.so.6 0xb7d35a01 abort + 257 2 llc 0x081a0972