On 2 March 2017 at 17:43, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > 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? You use the GEP API which allows you say that you want to access field 5 from a struct, and so on. Here 5 is the fifth field. LLVM works out the rest. This is better than casting the struct to char* and then doing pointer arithmetic. > > 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. > Sure but my experience with LLVM is that it needs to have type metadata for each store and load instruction to properly do type based alias analysis. Otherwise it will miss optimisation opportunities. Maybe we can still provide type metadata as we do have the symbol definition etc. But I agree that if sparse-llvm works correctly for all inputs then that is a big step forward (for me) ! 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
