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

[Gabor Greif]

Am 30.06.2010 um 23:31 schrieb John Criswell:

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

This is the case where I cannot help you (access via baseclass pointer).

For all these cases (there were a few in the llvm codebase too) I got
  - either assertion failures in the test suite
  - or obvious crashes
  - or miscompilations.

To catch all of these I could publish a patch (but not check it in)
that asserts that User::getOperand is not called on a CallInst.
But I can tell you that this will probably give you many false  
positives.

Btw. "method" above is of very little practical value, because
without knowing what type of instruction you have it makes
no sense to get its third operand. You will normally have a
dyn_cast<CallInst>(I) somewhere in "method".

Cheers,

	Gabor


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