[LLVMdev] alloc_size metadata

Hal Finkel hfinkel at anl.gov
Sat Jun 2 06:31:11 PDT 2012


On Sat, 02 Jun 2012 14:45:32 +0200
Duncan Sands <baldrick at free.fr> wrote:

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

I think this depends on when the passes run; looking at
PassManagerBuilder::populateFunctionPassManager it seems that the DCE
passes are all scheduled at the end. On the other hand, I recall that
other earlier passes also do some amount of DCE as well. That being the
case, if there is problem, we could develop some way to mark the
relevant values as 'used' and then remove those tags just prior to
running the real DCE passes at the end of the sequence.

 -Hal

> 
> Ciao, Duncan.



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list