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?> Then, after more cleanup has been done by other optimization passes, > run the pass that instruments the memory accesses (then DCE anything > that you did not end up actually using).Ciao, Duncan.
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. -Hal> > > Then, after more cleanup has been done by other optimization passes, > > run the pass that instruments the memory accesses (then DCE anything > > that you did not end up actually using). > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
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.