[LLVMdev] [HEADSUP] Another attempt at CallInst operand rotation
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
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
svn up -r 107580 llvm
Please follow up this mail if you have worries or
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.
> 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
>> 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
>> 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
>> 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