[LLVMdev] getIntrinsicID() optimization

[Nicolas Capens]

Hi Chris,

 

Function is currently 108 bytes large. Could 4 more bytes really be an
issue? 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 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.

 

Cheers,

 

Nicolas

 

  _____  

From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Saturday, 17 October, 2009 22:54
To: Nicolas Capens
Cc: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] getIntrinsicID() optimization

 

 

On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote:





Hi all,

 

While profiling I discovered that the Function::getIntrinsicID() method is
called a lot, and every time it uses string comparison to recompute the ID
number. As far as I know the name of an intrinsic function doesn't change,
so the ID could be determined just once at Function construction time.

 

I've attached a patch that does this and it appears to work for the code I
tested it with. Could anyone look at potential caveats and if there are none
commit it?

 

Hi Nicolas,

 

Sorry for the delay.  I don't think that this is the right way to go.
Making Function larger is an extremely expensive thing to do.  There are use
cases in LLVM where apps load large modules lazily and stream in functions
on demand.  The way this works currently is that the function objects are
created eagerly, but their bodies are lazy.  Increasing hte size of function
can substantially penalize these cases.

 

Also, as Jeffrey points out, it is not safe with setName().

 

However, this would be a great thing to have.  Instead of adding a new
field, is there space in the "SubClassData" field in Value?

 

-Chris

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091018/aad14a53/attachment.html>