[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!
John
More information about the llvm-dev
mailing list