[LLVMdev] speed and code size issues

John Regehr regehr at cs.utah.edu
Sat Jul 18 07:34:57 PDT 2009

Hi Nick, Daniel, Eli,

Well I think you hit the nail on the head that some way of sorting through 
the results is needed.  This should be feasible.  For example, we noticed 
that most or all of the programs miscompiled by Intel cc contain a mod 
operator; that sounds like a smoking gun.

An alternative to clustering results by bug is to be slow: fix the top 
bug, then rerun the tests, and find the new top bug.  This is what we 
usually do when submitting correctness bugs that come from random 
programs, since in the general case mapping failure-inducing tests back to 
their bugs is extremely difficult.

Eli you said that "fixing weird instcombine cases like that tends to be 
tedious and not very relevant."  Of course this is hard to argue with, but 
I would hope that once some tedious cases have been slogged through, some 
real issues would surface that would be more interesting.  Also note that 
while this collection of millions of functions is all simple integer 
expressions, we can also generate codes with loops, pointers, and other 
features that will stress different parts of the optimizer.

Anyway thanks for the good feedback.  I'm headed off on vacation today but 
will get these on the web fairly soon!


More information about the llvm-dev mailing list