Christopher Li wrote:
On Mon, Apr 27, 2009 at 3:28 AM, Jeff Garzik <jeff@xxxxxxxxxx> wrote:
Use of test-parsing eliminates my code as a factor -- which was why I
mentioned it.
Oh well, I will figure it out.
Let me take a look at your code as well. Maybe I can spot some thing.
linearized output is too low level for LLVM in several cases. The shifts in
linearize_load_gen() and linearize_store_gen() get in the way, for example.
Having sparse calculate struct offsets itself is also not desirable: in
order to use LLVM's getelementptr instruction, you should instead give LLVM
the type information and member indices, and let it figure out the address
calculation from there.
Right. I think GET_ELEMENT_PTR is the only part missing. I think it is
a relative small change to preserve the structure laid, comparing to rewriting
everything.
BTW, I don't think linearize lost that structure information. It
happens way before
linearize stage. Sparse converts the structure member access into void pointer
add very early on. If you want to preserve that information,
you need to change more than just linearize code. So linearize is not the
blocking factor here. It needs upstream change as well.
I just managed to figure out how to locate, enumerate and declare sparse
SYM_STRUCT to LLVM backend, in s2l-gen.c, without any upstream changes.
Thus, use of linearize would imply having to work backwards and recreate
information lost during the linearization.
Or, we can teach sparse to preserve that information in the linearize level.
Well, I'll tell you what. If you or somebody else wants to volunteer to
make key sparse & linearize changes, then I will work on a linearize
LLVM backend.
Absent that, the motivation is lower, considering I have a current,
working approach that does not require any upstream changes.
Jeff
--
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
