[RFC] Instruction API changes needed to eliminate debug intrinsics from IR

[jmorse]

Hi,

@hvdijk

The error I am getting seems to be due to Module::getOrInsertFunction creating a function outside of any module, implicitly using old debug info format, and then inserting it into the module. When Function’s constructor taking a parent module is used, the debug info format is now inherited from the module. Should Module::getOrInsertFunction do the same, or is it the responsibility of its users to set the debug info format?

That should be fixable (thanks for the PR!), it’s beginning to sound like this assertion is providing more noise than signal though. If the patch doesn’t fix it or if anyone else downstream is running into difficulties, we’ll downgrade it to some kind of warning or optional development aid. (As mentioned elsewhere, it used to be useful, but it doesn’t look like it is any more).

Another question, based on [link] That means when writing passes that insert LLVM IR instructions, you need to identify positions with BasicBlock::iterator rather than just a bare Instruction *: what is the intended update of code that calls e.g. BinaryOperator::Create* which take only an Instruction * and have no overload that takes a BasicBlock::iterator ?

Good question – ultimately these should become methods that take iterators, we’ll be sweeping the codebase to provide both shortly, and eventually only iterators. For the time being code that inserts with an Instruction * runs the risk of changing the position that variable locations appear at the start of a block, in some rare circumstances. Those will go away when insertion is via iterators.

That’s actually the summit of the whole piece of work here: carrying a bit of information via the iterators means all the debug-info accounting can happen in the background. It’s what’s going to free us all from skipDebugIntrinsics and similar debug-info mangling during analyses!