On Sun, Aug 28, 2011 at 12:31 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
>
> But that comment was thinking more medium term, supporting multiple
> platforms means properly handling struct layout in memory, which gets into
> the realm of platform-specific ABIs.
>
> It didn't seem like we would want to encode a ton of ABI detail into the
> sparse C front-end. But it sounds like there will be a lot of ABI detail
> found, if sparse is doing all the memory layout and such.
But you *have* to encode it into the front end.
Things like size and alignment of types is exactly what sparse was all
about from the beginning. And if the front-end doesn't know the
offsets into structures, it cannot do any of the load/store
optimizations, which all very much depend on alias information, and
which are how sparse does a lot of the semantic analysis.
A number of the things sparse already does (ie the lock analysis etc)
very much depends on being able to do CSE over accesses to local
variables etc, which originally were memory operations - turning those
memops into registers etc is how sparse can follow things like
branches to branches and optimize them away, which it needs to handle
things like "if (trylock()) -> unlock" sequences.
Now, admittedly we could do much of that without necessarily handling
the *generic* case of loading/storing to structure members etc,
because the case we tend to care about in the sparse code analysis
phase tends to be about the trivial "local variable" case, so in that
sense sparse does a lot more than strictly necessary for just
following the code. But it's much nicer (I think) to have a tool that
really understands the code, than just apply patterns to it.
Of course, "just applying patterns to it" is actually what coccinelle
does, and it has been very successful. So ..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
