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. > 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. > The general idea with LLVM bitcode is to pass it type information, and it > will ensure that bitfields are handled properly, structs are laid out and > padded properly, function return types handled, etc. LLVM handles all the > address generation for us, once we give it enough type info. Currently the linearize instruction already has the C type information. David's compiler back end needs that. We still need the structure laid though. Chris -- 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
