[llvm-commits] [llvm] r73646 - /llvm/trunk/include/llvm/Support/IRBuilder.h

[Nick Lewycky]

Chris Lattner wrote:
> On Jun 18, 2009, at 1:10 AM, Anton Korobeynikov wrote:
> 
>> Hi Chris
>>
>>> Anton, why isn't the caller and callee already getting the right
>>> calling conv?  This seems like the wrong fix,
>> We have separate calling conv fields on, for example, Function and
>> CallInst. That's why API user should put correct calling conv on
>> CallInst during creation of such (see, for example,
>> SimplifyCFGPass.cpp:ChangeToCall). By default CI's are created with C
>> calling conv and in general we'll have calling conv mismatch between
>> caller and callee if API user won't tune the calling conv of CI.
>>
>> SimplifyLibCalls pass uses IRBuilder to insert calls to strlen &
>> friends. They can be already defined in the module with non-C calling
>> convention, thus we need to put the same calling conv on CI also. I
>> thought it's much safer to let IRBuilder to do this by default instead
>> of letting each user to do this explicitly. Also, since custom CCs are
>> not so frequent stuff, possible bugs due to CC mismatch might be
>> pretty tricky to catch of we'll delegate tweaking of CC to API user.
> 
> I discussed this with Anton on IRC and convinced (I think!) him to  
> revert the changes to IRBuilder.  I'd like to keep it really obvious  
> how the IRbuilder interfaces relate to the generated IR.  One of my  
> fears is that making this be "magic" will make enough stuff work in  
> the obvious cases that we'll be left with obscure bugs in the uncommon  
> cases.  By making the client have to directly think about CC's, we  
> avoid some bugs.

That's the situation now, after the revert. Things will work by "magic" 
almost all of the time, until we hit an obscure bug in the uncommon case 
that somebody actually set a non-zero CC on a function.

If you really want to go down this road I suggest making the CC a 
required parameter to CreateCall.

Nick