[LLVMdev] PredicateSimplifier questions

John Regehr regehr at cs.utah.edu
Sun Feb 15 21:59:20 PST 2009


Thanks for the answers Nick!

> I wrote predsimplify as I was learning about compiler theory. It's
> pretty dumb in the sense that it spends lots of time analysing things
> that will never be used, and despite being the slowest pass in LLVM I
> haven't seen it improve run-times in a nightly test.

Interesting.  The application I have in mind here is some TinyOS code 
where we've added lots of array bounds checks.  The vast majority of these 
in fact cannot fail but LLVM and GCC are not smart enough to see this. 
It seemed like predsimplify was probably the right pass for this, but I 
haven't studied its success rate yet.

The problem isn't execution cost but rather code size.  This is for the 
msp430 platform which has too little flash memory.  The code bloat really 
is a showstopper here: a number of existing applications overflow the 
available memory when we add checking, and cannot be run!  (This is using 
gcc, we do not yet have an LLVM port to msp430.)

So the "pluggable domain" thing (an idea we had good luck with at the 
source level using CIL) is not just for compiler class, but also for 
solving this real problem.  In addition to calling out to standard 
abstract domains I want to for example play with shelling out to a 
heavyweight decision procedure.  This should make many spurious bounds 
checks go away.  Greg Morrisett reports good success with this approach in 
the Cyclone compiler.  Inspection of embedded codes shows that most array 
accesses can be proved to be in bounds pretty easily-- though these proofs 
are apparently out of reach of -O2 type optimizers.

> Predsimplify is believed to have bugs (it results in miscompiled
> programs) and certainly isn't efficient (it was written before much of
> include/ADT). Finally, predsimplify is likely to go away once I or
> someone else writes a proper VRP pass.

Well I do have a good way to find integer miscompilations... but don't 
want to waste everyone's time if this pass is on the way out.

John Regehr



More information about the llvm-dev mailing list