[LLVMdev] LLVMBuilder vs LLVMFoldingBuilder

[Dominic Hamon]

Chris Lattner wrote:
> On Apr 2, 2008, at 9:54 AM, Dominic Hamon wrote:
>   
>> Would it be reasonable for me to submit a patch whereby the  
>> LLVMBuilder
>> methods also return the general Value* type and the LLVMFoldingBuilder
>> methods become virtual overrides of the base class methods?
>>     
>
> No, please don't do this.  The idea of llvmbuilder is that it is a  
> "free" wrapper around the other existing API calls.  Making the  
> methods virtual would make them much more expensive.
>
>   
Is this why the other API calls are all inline in the class? To avoid 
the overhead of the function call?
>> Users (such as myself) could then decide at runtime which type of
>> builder they wish to use.
>>     
>
> Why do you want this?
>   
At the time that I was considering this, I saw that the Folding Builder 
was a derived class of Builder and assumed, apparently wrongly, that the 
intention was to create further derived versions of the Builder with 
other potential optimisations.

If the Folding Builder is meant as a general replacement for the 
Builder, then the second approach does make much more sense.

>> Another option that was discussed in #llvm is to nuke LLVMBuilder and
>> rename LLVMFoldingBuilder to LLVMBuilder.
>>     
>
> I'd strongly prefer this.  The non-folding builder is not very useful  
> for anything, and anyone who wants unfolded instructions can call the  
> instruction ctors directly.
>
>   
>> If this was the case, I'd
>> argue for a flag in the Builder that could retain the old non-folding
>> functionality for debugging purposes.
>>     
>
> Why?
>
>   
I used this non-folding functionality to create more explicit IR that I 
could check against my input to my parser. It made debugging far easier 
in the early stages of adding new parsing functionality.

Dom