[LLVMdev] [HEADSUP] Another attempt at CallInst operand rotation

Gabor Greif gabor at mac.com
Wed Jun 30 13:59:07 PDT 2010


Hi all,

I am almost ready for the last step with landing my long-standing patch.
I have converted (almost) all low-level interface users of CallInst to
respective high-level interfaces. What remains is a handful of hunks
to flip the switch.

But before I do the final commit I'd like to coerce all external users
to code against the high-level interface too. This will (almost, but
see below) give us static guarantees that out-of-tree code remains
functional across this transition.

Here is my attack plan:

I will fire two rounds,
- the first will catch all instances of CallInst::get/setOperand(0, ...)
   and suggest using get/setCalledValue (or getCalledFuntion).
- the second will make all low-level operand accessors private
   in CallInst, and thus give external clients the chance to use
   *ArgOperand* versions. This will be well-commented in the
   header, explaining the recommended way of accessing
   arguments.

At this point we will have caught 99% of all low-level clients out  
there.

What uncertainties will remain? I can think of two of them:

   o getOperandNo()
   o access via baseclass pointer

The former is a method on Value::use_iterator and I cannot see a way to
intercept it at compile-time.
The latter is always possible and does circumvent the above measures,
there is no remedy against it.

I plan to fire each of these two rounds with one week delay and monitor
the LLVM mailing lists while they are soaking.

After that I'll commit the actual operand rotation.

Last but not least, there will be some cleanup commits:

  - removing CallInst::ArgOffset,
  - fixing the 80-column violations I have introduced,
  - doxygenizing the new interfaces,
  - re-enabling the low-level interface again (possibly
    after 2.8 has brached?).

Well, that's it. I hope that this order of commits will keep
the pain at a bearable level for everyone.

I would be thankful for any comments/suggestions
regarding this plan.

Cheers,

	Gabor






More information about the llvm-dev mailing list