[LLVMdev] Unused malloc/free don't get optimized

[Reid Spencer]

Hi Nicola,

On Wed, 2007-02-14 at 18:54 +0100, Nicola Lugato wrote:
> I've made some other test and it looks like it don't remove even
> simple malloc/free couple. Maybe there's something wrong in the way i
> use the opt command.

No, there's not. LLVM doesn't provide the transform you want. As Chris
mentioned, if you open a Bugzilla report (http://llvm.org/bugs) and ask
for the feature we are more likely to get it done than if you don't.

> How can i tell him to optimize at best, whitout
> specifing each pass? I'm not using c/c++ frontend, just the assembler.

The opt tool recently acquired a new option (--std-compile-opts) which
performs the set of optimizations that gccas used to provide. This set
of options is intended for use with code compiled by llvm-gcc. You might
also find it useful. However, the set of passes to run to produce the
best code depends on a lot of factors. The source language is one of
those factors. The program compiled is another. In general there is no
way to come up with the "ultimate" set of passes that produce the best
results for all inputs. However, --std-compile-opts is a close
approximation for C-like languages compiled by llvm-gcc.

Reid.

> 
> Thanks in advance
> 
> On 2/14/07, Chris Lattner <sabre at nondot.org> wrote:
> > On Tue, 13 Feb 2007, Nicola Lugato wrote:
> > > Hi, i have some code that allocate some memory, store the pointer to a
> > > variable, read it back and deallocates it, like this:
> >
> > ok
> >
> > > i expected the optimized to remove everything, but after running it
> > > the code i get is:
> > >
> > > int %main(int %argc, ubyte** %argv) {
> > >       %malloc_206 = malloc [10 x ubyte]
> > >       %malloc_206.sub = getelementptr [10 x ubyte]* %malloc_206, int 0, int 0
> > >       free ubyte* %malloc_206.sub
> > >       ret int 0
> > > }
> > >
> > > Why didn't he optimized it out?
> >
> > This looks like a simple missed optimization.
> >
> > > and where did that getelementptr came from?
> >
> > This is just passing a pointer to the first byte of the array into the
> > free instruction.  This has the same semantics as freeing the pointer to
> > the array, since they are the same value.
> >
> > > I have the feeling that i'm missing something.
> >
> > Nope, I don't think so.  Please feel free to file an enhancement request
> > for us to catch this case!
> >
> > -Chris
> >
> > --
> > http://nondot.org/sabre/
> > http://llvm.org/
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev