[LLVMdev] readonly and infinite loops

Hal Finkel hfinkel at anl.gov
Tue Jun 30 14:35:44 PDT 2015


----- Original Message -----
> From: "Nuno Lopes" <nunoplopes at sapo.pt>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy
> Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com
> Sent: Tuesday, June 30, 2015 4:30:15 PM
> Subject: Re: [LLVMdev] readonly and infinite loops
> 
> >> Interesting.  Could you give an example why knowing a function
> >> will
> >> halt is
> >> essential for the heap-to-stack conversion?
> >
> > The key situation you need to establish in order to do
> > heap-to-stack
> > conversion, is that you can see the calls to free (or realloc,
> > etc.) along
> > all control-flow paths. If you can, then you can perform the
> > conversion
> > (because any additional calls to free that you can't observe would
> > lead to
> > a double free, and thus undefined behavior). Thus, if we have this
> > situation:
> >
> > void bar(int *a);
> > void foo() {
> >   int *a = (int*) malloc(sizeof(int)*40);
> >   bar(a);
> >   free(a);
> > }
> >
> > we can perform heap-to-stack conversion iff we know that bar(int *)
> > always
> > returns normally. If it never returns (perhaps by looping
> > indefinitely)
> > then it might capture the pointer, pass it off to some other
> > thread, and
> > that other thread might call free() (or it might just call free()
> > itself
> > before looping indefinitely). In short, we need to know whether the
> > call
> > to free() after the call to bar() is dead. If we know that it is
> > reached,
> > then we can perform heap-to-stack conversion. Also worth noting is
> > that
> > because we unconditionally free(a) after the call to bar(a), it
> > would not
> > be legal for bar(a) to call realloc on a (because if realloc did
> > reallocate the buffer we'd end up freeing it twice when bar(a) did
> > eventually return).
> 
> I see, thanks!
> Your argument is that knowing that bar returns implies that 'a'
> cannot be
> captured or reallocated, otherwise it would be UB. 

Yes. Technically, it can be captured, it just does not matter if it is captured, but the captured value is 'dead' once you pass the call to free(a).

 -Hal

> Makes sense, yes.
> 
> Thanks,
> Nuno
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-dev mailing list