Alloca with LLVMContext

Dear All,

Is there a reason why the AllocaInst constructor takes an LLVMContext
argument? Can't it just determine the context from either the basic
block or instruction pointer argument?

If the constructor can infer the context automatically, that would save
one API change.

If the constructor can't infer it, would it be possible to make the
context the last parameter and have it use a default LLVMContext (say,
the one from getGlobalContext())?

Either of these would ease the transition effort.

-- John T.

Dear All,

Is there a reason why the AllocaInst constructor takes an LLVMContext
argument? Can’t it just determine the context from either the basic
block or instruction pointer argument?

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.

This problem was simpler 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.

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.

If the constructor can’t infer it, would it be possible to make the
context the last parameter and have it use a default LLVMContext (say,
the one from getGlobalContext())?

Possibly. I’ll look at it when I get in.

–Owen

I must have missed something. I think you've said that all Types will
have a Context, in which case the AllocaInst could pull the context
from its type.

Jeffrey

They probably will at some point, in which case this will make sense. However, it is not possible to introduce that incrementally. Adding a context reference to Type will require either passing an LLVMContext into every type constructor (which would create EVEN MORE temporary API changes), or a branch/patch dump (which is contrary to LLVM development policy).

I'm trying to make the minimally intrusive set of API changes to support pushing LLVMContext through things, but some temporary changes are unavoidable in order to make incremental development possible.

--Owen

After considering this more, and some discussion on IRC, I've decided that this is a good way to proceed, and will hopefully obviate the need to pass LLVMContext's into most APIs, including the AllocaInst change.

Look for the introduction of contexts-on-types in the near future, and the removal of LLVMContext parameters from methods where it can be inferred from a Type.

--Owen