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

[Chris Lattner]

Sounds great to me Gabor.  I really like your new incremental approach to this patch set.

-Chris

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
>   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
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev