> Maybe a similar interface could be added to Instruction, and an > instruction would declare itself unsafe to clone if 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 Parzyszek [kparzysz at codeaurora.org] Sent: 01 December 2012 17:19 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] "noclone" function attribute On 12/1/2012 10:02 AM, James Molloy wrote:> > I'm proposing a new function attribute, "noclone", with the semantics 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(); I != E; ++I) { if (isa<IndirectBrInst>((*I)->getTerminator())) return false; } return true; } Maybe a similar interface could be added to Instruction, and an instruction would declare itself unsafe to clone if it was a call to a function with the attribute that you are proposing. I could imagine that this may not the only example of an instruction that should not be cloned. I'd only suggest that the attribute is called something like "noclonecalls", or (preferably) something shorter that clarifies that it's the calls that shouldn't be cloned. :) -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 12/1/2012 11:25 AM, James Molloy wrote:>> Maybe a similar interface could be added to Instruction, and an >> instruction would declare itself unsafe to clone if 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.I guess the problem would be when the compiler wants to clone the instruction with the plan of deleting the original later. In such a scenario there could be temporarily (and legitimately) multiple calls to the barrier. An example could be inlining of the only call to a static foo, which contains a call to "barrier". Checking of issues with split barriers could be done by the module verifier. We would need to make all the calls to barrier unique at the beginning (for example, by passing a fake, compiler-generated identifier as an argument). The module verifier could check that in a given module there are no multiple calls to "barrier" that have the same identifier. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> Checking of issues with split barriers could be done by the module > verifier. We would need to make all the calls to barrier unique at the > beginning (for example, by passing a fake, compiler-generated identifier > as an argument). The module verifier could check that in a given module > there are no multiple calls to "barrier" that have the same identifier.I like that idea, as long as we can find a way to implement it that isn't a hack in any way. The IR doesn't know about "barriers" (hence the concept of a noclone attribute), and we can't make the module verifier be stateful (knowing what noclone insts were around last time, comparing it with this time). So I'm not sure how we'd do this without it being a hack in some way... ________________________________________ From: Krzysztof Parzyszek [kparzysz at codeaurora.org] Sent: 01 December 2012 17:40 To: James Molloy Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] [RFC] "noclone" function attribute On 12/1/2012 11:25 AM, James Molloy wrote:>> Maybe a similar interface could be added to Instruction, and an >> instruction would declare itself unsafe to clone if 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.I guess the problem would be when the compiler wants to clone the instruction with the plan of deleting the original later. In such a scenario there could be temporarily (and legitimately) multiple calls to the barrier. An example could be inlining of the only call to a static foo, which contains a call to "barrier". Checking of issues with split barriers could be done by the module verifier. We would need to make all the calls to barrier unique at the beginning (for example, by passing a fake, compiler-generated identifier as an argument). The module verifier could check that in a given module there are no multiple calls to "barrier" that have the same identifier. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation