[LLVMdev] Passes for object memory footprint / data-direction

[Duncan Sands]

Hi Sebastian,

On 18/02/13 19:02, Sebastian Dreßler wrote:
> Hal,
>
> On 02/18/2013 06:33 PM, Hal Finkel wrote:
> [...]
>
>>> In the past months we were working on two LLVM passes which use
>>> data objects of functions as input. One pass computes the
>>> "data-direction" (FORTRAN users know this as intent) of the
>>> object, i.e. whether it is read-only, write-only or read-write. The
>>> second pass injects code into the LLVM module that, when called at
>>> run-time, computes the memory footprint of the object. This also
>>> works for non-linear objects, e.g. linked lists or instances of
>>> std::map. Dynamic allocation is also supported, with some
>>> limitations.
>>>
>>> Our original aim was to use these passes for a scheduler developed
>>> in the project we are currently involved (ENHANCE,
>>> http://www.enhance-project.de). However, I'm curios to hear
>>> whether these passes could also be useful for other LLVM developers
>>> / users.
>>
>> Sebastian,
>>
>> These sounds quite interesting. Can you explain a little more about
>> how they work? How they scale? Do they work with objects used across
>> multiple modules? If so, does that require the use of LTO?
>>
>
> Unfortunately I cannot provide too much details, because we've made a
> conference submission and it is pending (not Euro-LLVM). However, I'll
> try to answer your questions:
>
> Both approaches first construct a graph containing the needed
> information. This eases the following analysis a bit and we also want to
> re-use them for other "problems".
>
> Direction determination is completely static and basically works by
> performing points-to analysis and counting *relevant* loads / stores.
> Based on the load / store ratio we then assign a direction label to the
> object.

I think there's an old bug report requesting per-parameter readonly/readnone
attributes.  This would be pretty useful.  It sounds like you've implemented a
pass that determines them.  Maybe you could integrate it into the existing
FunctionAttrs pass, and have it generate such per parameter attributes.

Ciao, Duncan.