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

Gabor Greif gabor at mac.com
Mon Jul 5 13:19:26 PDT 2010


Round one has been committed as

I hope that it got digested by now, as I plan to commit the second
round tomorrow.

In fact I made two test commits already:
r107480 and r107580, the former of which
actually uncovered some more uses of the
low-level interfaces in core LLVM that
have slipped through.

To be prepared, you can do a test run with
your external tree if you wish using the
latter revision:

svn up -r 107580  llvm

Please follow up this mail if you have worries or
encounter problems.



Am 01.07.2010 um 06:41 schrieb 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

More information about the llvm-dev mailing list