On Mon, Apr 27, 2009 at 6:21 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote: > Christopher Li wrote: >> >> On Mon, Apr 27, 2009 at 5:32 PM, Jeff Garzik <jeff@xxxxxxxxxx> wrote: >>> >>> Not true -- I can walk SYM_STRUCT of the function arguments' base_type >>> passed to a SYM_FN. Similarly so for struct-based variable declarations. >>> >>> With that information, you can easily back-reference lvalue uses to the >>> original struct. >> >> Let say I follow this route, isn't that you can apply the same trick for >> the >> linearize instruction case? struct instruction has a type member give a >> pointer to C type. >> >> I still don't see a reason why you have to use your own AST recursive >> code. > > You mean, besides the reasons already listed? Namely, no upstream changes > are required, and I already have something that works. > > Sure, the same trick can be applied. But that requires a total backend > rewrite plus dealing with linearize obstacles already described (ref > linearize_load_gen, linearize_store_gen). Thus it is obviously a lot more OK. The current handling of linearize_load_gen and linearize_store_gen is annoying when you try to treat bit field as a type. On the other hand, your V2 patch does not have bit field (yet). In the long run, I would rather have only one implementation of the linearization. I will take a look at how LLVM does bit fields and get back to you. 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
