[LLVMdev] alloc_size metadata

[Duncan Sands]

Hi Hal,

On 02/06/12 14:28, Hal Finkel wrote:
> On Sat, 02 Jun 2012 09:56:30 +0200
> Duncan Sands<baldrick at free.fr>  wrote:
>
>> Hi Hal,
>>
>>> To do bounds checking you need two things: First you need to know
>>> the bounds (this requires tracking calls to allocation functions),
>>> and then you need to look at memory accesses. My guess is that
>>> running the analysis late helps much more with the second part than
>>> with the first. So I would split this into two pieces. Prior to
>>> inlining, add whatever is necessary around each call site so that
>>> you get the bounds data that you need. You can tag these resulting
>>> values so that they're easily recognizable to the later parts of
>>> the analysis (you might need to artificially makes these 'used' so
>>> that DCE won't get rid of them).
>>
>> in that case, why not have the front-end do this part?  I mean, rather
>> than the front-end outputting hi/lo functions and metadata so that
>> some LLVM pass can insert a few markers or whatever around/on
>> call-sites that a later LLVM pass recognizes, why not have the
>> front-end insert those "markers" directly?
>
> So long as this does not violate the "don't pay for what you don't
> use" rule, I don't see any reason why not.

the question then arises of what those "markers" should be, and kind of brings
things full circle to Nuno's original suggestion of calculating the hi/lo bounds
explicitly just before the call to wonder_malloc, and sticking metadata on the
call to say "this value holds the lower bound and this one the upper".  The
problem with that is presumably that the optimizers will just zap the apparently
unused hi/lo values.

Ciao, Duncan.