On 2 March 2017 at 17:18, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Thu, Mar 02, 2017 at 04:30:53PM +0000, Dibyendu Majumdar wrote: >> > Here is the output from linearize. I think the way stores and loads >> > are handled is broken. It appears that the last store / load >> > instruction is stored in insn->target->priv, and then used later on >> > ... I do not understand what the code is trying to do. Is it trying to >> > optimize away stores and loads? > > No, no. > What is stored in ->priv is the target's LLVMValueRef (and for a store > the 'target' is what need to be stored). > And indeed there is a bug there: it's target_in that should be stored in > ->priv (in fact, for a store, there is no need to put anything at all > in this field; at least I don't see any reason why it should). > Nice catch. > I don't know how it's related to your problem though. > My question was why is something being stored in 'priv' and used later? That seems to be an optimisation? Why not recompute every time? I think this caching in 'priv' and using it later is the cause of the wrong code - unless as you say the value stored in 'priv' is incorrect and needs fixing. Regards -- 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
