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. How can i tell him to optimize at best, whitout specifing each pass? I'm not using c/c++ frontend, just the assembler. 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 >
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
Reid Spencer wrote:> 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.That's surprising to me. I thought there was a pass that converts malloc's that trivially dominate all free's and whose pointer doesn't escape would be lowered to alloca's -- but I looked and couldn't find one. Why isn't there one? Because it wouldn't be profitable? Or because the alias analysis is too complex? Or just because nobody's gotten to it yet? I would've thought that this pattern would occur rather often. I know I've written code that strdup's a value, reads/writes it, then frees it. After inlining the strdup, changing the malloc/free to alloca should be easy. That said, you'd have to be careful to ensure that the malloc-free pair isn't inside of a loop before converting it to alloca. Regardless, I'd be interested in implementing this in a pass if noone else does. Nick Lewycky