[LLVMdev] [HEADSUP] Another attempt at CallInst operand rotation
clattner at apple.com
Wed Jun 30 21:41:47 PDT 2010
Sounds great to me Gabor. I really like your new incremental approach to this patch set.
On Jun 30, 2010, at 1:59 PM, Gabor Greif wrote:
> 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
> At this point we will have caught 99% of all low-level clients out
> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev