An LLVM backend for Sparse

Posted Aug 31, 2011 12:23 UTC (Wed) by ortalo (guest, #4654)
In reply to: An LLVM backend for Sparse by penberg
Parent article: An LLVM backend for Sparse

What are the practical improvements you expect (or have already obtained) for sparse analysis results from being able to produce working code? Maybe some examples would help me understand the kind of things you target?

BTW, would these results be generalizable to GCC-produced kernels or not? For example, if you can guarantee that the sparse+LLVM-compiled kernel does not exhibit some specific kind of programming error, would this be applicable to the same kernel compiled by GCC?
I expect a no, but I do not understand all the details.

Rodolphe

PS: I do not want to enter the Clang vs sparse debate. I've listed both on the same course slide for several years; and I am *very* happy to see *both* tools making advances.
Such static analysis topics seem intrinsicly difficult (at least, that's what the students seing the above mentionned slide feedback to me). It would be nice if both of you could provide more details (even 2 articles) on the recent advances and remaining perspectives in their respective projects, instead of well... you see what I mean. That wouldn't be duplicated effort because well, maybe the most difficult in this area is to teach would-be developers how to help.

An LLVM backend for Sparse

Posted Sep 1, 2011 5:44 UTC (Thu) by penberg (guest, #30234) [Link]

> What are the practical improvements you expect (or have already obtained) for
> sparse analysis results from being able to produce working code?

For example, Jeff discovered problems in the linearized IR which were caused by
bugs in the CSE algorithm that were fixed by Kamil Dudka:

https://github.com/penberg/sparse-llvm/commit/556cb86326b...

https://github.com/penberg/sparse-llvm/commit/7ac3e4bd792...

I don't know what practical problems that specific problem caused for the
'semantic analysis' parts but I'd assume it falls into either 'false positive'
or 'false negative' errors in some of the semantic checks. We've also
discovered problems in the way Sparse handles the C99 _Bool data type and
several weaknesses in its floating point support. That said, it's been a pretty
smooth ride so far.

Hopefully the outcome of the project is that sparse's semantic analysis will be
more accurate. I'm also testing sparse-llvm against sparse itself so hopefully
we'll improve support for non-kernel projects as well. I don't know the
frontend side of things so I don't know if there's other things on the semantic
analysis side we'll help with.

> BTW, would these results be generalizable to GCC-produced kernels or not? For
> example, if you can guarantee that the sparse+LLVM-compiled kernel does not
> exhibit some specific kind of programming error, would this be applicable to
> the same kernel compiled by GCC?

Even if the kernel compiles with sparse-llvm, the results with GCC might still
be completely different. Maybe there's a bug in sparse-llvm that masks an error
or maybe there's a bug in GCC. The whole point of semantic analysis on C is to
discover errors, not to prove correctness of the program.

> PS: I do not want to enter the Clang vs sparse debate.

I think it's pointless to even compare the two. Sparse is much smaller and more
limited than Clang and the heavy lifting is being done by LLVM for both.