Re: Sparse-LLVM issue compiling NULL pointers

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Thu, Mar 2, 2017 at 7:58 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 2 March 2017 at 17:43, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> 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.

OK. Yes.

>> 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.

There is certainly no reasons to not give easily available information.

> But I agree that if sparse-llvm works correctly for all inputs then
> that is a big step forward (for me) !

Indeed :)


Luc