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

[John Criswell]

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.
>   

Stupid question: is making the getOperand() method of CallInst going to 
work?  For example, if I have the following code:

void
method (Instruction * I) {
    I->getOperand(2);
    ...
}

void method2 (CallInst * CI) {
    method (CI);
    ...
}

Will method() still work when you make CallInst::getOperand() private?

-- John T.

> 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
>