search for: issafetoclon

...cs that "calls to functions marked "noclone" cannot be cloned or duplicated into the same function.". That is, it is illegal to call J = I->clone() then attach J to the same basic block as I if I is marked "noclone". The class Loop has something similar in it: /// isSafeToClone - Return true if the loop body is safe to clone in practice. /// Routines that reform the loop CFG and split edges often fail on indirectbr. bool Loop::isSafeToClone() const { // Return false if any loop blocks contain indirectbrs. for (Loop::block_iterator I = block_begin(), E = block_end...

...f it was a call to a > function with the attribute that you are proposing. I experimented with something similar to this, where Instruction::clone ensured it wasn't "noclone" - if it was, it asserted. But that broke the use-case of cloning whole functions. My patch extends Loop::isSafeToClone to check if a callinst is contained which is "noclone". I agree about the naming, but have yet to think of something more snappy :) Cheers, James ______________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzysz...

Hi, OpenCL has a "barrier" function with very specific semantics, and there is currently no analogue to model this in LLVM. This has been touched on by the SPIR folks but I don't believe they put forward a proposal. The barrier function is a special function that ensures that all workitems executing a kernel have executed up to that point before execution on any workitem can

Dear all, Here's an updated version of the parallel loop metadata patch. It includes documentation for the new metadata types with a semantics description. -- Pekka -------------- next part -------------- A non-text attachment was scrubbed... Name: parallel-loop-metadata.patch Type: text/x-patch Size: 12972 bytes Desc: not available URL:

On Wed, Jan 30, 2013 at 12:35 PM, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > Thank you all for comments, > > > On 01/30/2013 11:22 AM, David Tweed wrote: >> >> In a personal capacity I'm quite interested in the issues of producing >> from a >> high-level language some LLVM IR which is labelled with vectorization info >> (including