[LLVMdev] getIntrinsicID() optimization

[Chris Lattner]

On Oct 17, 2009, at 4:57 PM, Nicolas Capens wrote:

> Hi Chris,
>
> Function is currently 108 bytes large. Could 4 more bytes really be  
> an issue?

Yes.  :)

> Actually 2 should suffice. While I understand that some applications  
> value storage more than anything, many applications value  
> compilation time very highly. getIntrinsicID is called all over the  
> place (isIntrinsic uses it as well), and every single time it checks  
> the function name. To me that sounds a lot more dramatic than 2 bytes…
>
> Anyway, using SubclassData could work. It’s already being used for  
> the calling convention, which has values ranging from 0 to 68  
> (fitting in 7 bits), while intrinsic ID’s would take 9 bits. So that  
> would only just work. However, the calling convention enums could be  
> reordered to only take 3 bits.

I think that fitting it into SubclassData would be best.

> I was wondering whether it would make sense to have an  
> IntrinsicFunction class, derived from Function. This way only the  
> IntrinsicFunction would have an intrinsicID field. I noticed that  
> Function already has virtual methods so getIntrinsicID could be  
> another virtual method without adding any real overhead. For  
> Function it would simply return 0 while for IntrinsicFunction it  
> returns the intrinsicID field that was initialized in the constructor.


It would be fine to have a stateless IntrinsicFunction class (Similar  
to IntrinsicInst) but it wouldn't work to add state there.  We do need  
setName etc to work.  The bytecode and .ll parsers have to play games  
when autoupgrading old .ll files, and we want the IR manipulation  
methods to be simple and consistent where possible.  I completely  
agree that making getIntrinsicID() fast is a worthwhile goal, lets  
just not lose anything else in the process :)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091017/50a16e99/attachment.html>