On Thu, Mar 02, 2017 at 05:18:16PM +0000, Dibyendu Majumdar wrote: > Hi Luc, > > I was looking at whether I can use the standard LLVM GEP api to access > struct and array members in sparse-llvm. I noticed that the output > from sparse has byte offsets of each member - but not the member's > ordinal position. Indeed, when the offset is a compile constant otherwise the offset is set to zero and there is a pair OP_MUL/OP_ADD before that does the needed pointer arithmetic. > To use the native LLVM methods we would have to > allow LLVM to work out byte offsets, and just use the struct or array > definition. This would I think make the code more robust and also lead > to better optimisation. I'm not sure to understand here: which byte offsets need to be worked out? Also, for the optimization, I wouldn't worry for now because: - the linearized code is already optimized (nothing sophisticated but the essential is already there) - you can always later call LLVM's optimization passes - the code selector will also do some optimization. > Unfortunately LLVM does not support unions so for unions a bit of what > is being done now is probably needed, but even here it is better to > cast a union to its member struct type and then use LLVM GEP api to > access its members. > > What do you think? Honestly, I think nothing because I don't understand enough the issues with sparse-llvm and what LLVM needs. > I think adding the ordinal position to sparse symbols is a trivial > enhancement - do you agree? Unless I'm misunderstand what you mean, these postion are already there but not explicitly: you can lookup the lists to see what position a field in a structure is. If you need the byte offsets, those are already available (or trivialy calculable). Luc -- 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
