<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 15, 2009, at 8:14 AM, John Criswell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Dear All,<br><br>Is there a reason why the AllocaInst constructor takes an LLVMContext<br>argument? Can't it just determine the context from either the basic<br>block or instruction pointer argument?<br></div></blockquote><div><br></div><div>BasicBlocks and Instructions don't necessarily have contexts, if they're not attached to a module. You can also construct an AllocaInst without attaching it to a BasicBlock.</div><div><br></div><div>This problem was <i>simpler</i> for global values, where they're attached directly to a Module, which must have a context. There I was able to split it into constructors that take mandatory contexts and ones that take mandatory modules. With Instructions, it doesn't work so well, because even if I make the BasicBlock mandatory, there is not guarantee that it is attached to a Module.</div><div><br></div><div>This could be an argument for pushing the context member does into BBs and Instructions, but that has performance and memory use implications that I haven't considered yet.</div><div><br></div><blockquote type="cite"><div>If the constructor can't infer it, would it be possible to make the<br>context the last parameter and have it use a default LLVMContext (say,<br>the one from getGlobalContext())?<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>Possibly. I'll look at it when I get in.</div><div><br></div><div>--Owen</div></body></html>