similar to: [LLVMdev] Strange LLVM Crash

Ok, well, I seem to have pinpointed the cause of the problem more accurately. I'm running some optimization passes on my module after I compile each function in my scripting language (functions can be compiled at various times, when scripts are loaded). Now it seems these optimization passes will prune some of the native C++ functions I'm registering in my module (the functions that

I don't know how to do that. Rather new to LLVM. The functions that get stripped out are native C++ functions that I'm registering in my execution engine by doing: // Create a function type object for the function llvm::FunctionType* pFuncType = llvm::FunctionType::get(returnType, argTypes, false); // Create a function object with external linkage and the specified

Nyx wrote: > The linkage type is set to external, I have little code snippet I use to > register those native functions in the first post of this topic. The global > DCE pass deletes the unused native functions when run. I commented it out > for now... Can you make this happen by writing a custom .ll to demonstrate the problem? For example: $ cat gdce.ll define i32 @foo() {

Nyx wrote: > Ok, well, I seem to have pinpointed the cause of the problem more accurately. > I'm running some optimization passes on my module after I compile each > function in my scripting language (functions can be compiled at various > times, when scripts are loaded). Now it seems these optimization passes will > prune some of the native C++ functions I'm registering in

The linkage type is set to external, I have little code snippet I use to register those native functions in the first post of this topic. The global DCE pass deletes the unused native functions when run. I commented it out for now... Nick Lewycky wrote: > > Nyx wrote: >> Ok, well, I seem to have pinpointed the cause of the problem more >> accurately. >> I'm running

Hi, Until recently I've been building LLVM with SHARED_LIBRARY=1. However, sith current svn, build now fails with unresolved symbols building opt. I've done a clean checkout, configure and make so it's not down to any local changes I've made. I'm building with: ./configure --enable-assertions \ --enable-expensive-checks=no \ --enable-pic \ --enable-targets=host-only \

Hi Devang, > You can do inlining even when flag_unit_at_a_time is off. And one can > enable unit-at-a-time without enabling any optimizations. The unit-at- > a-time is not meant to select optimization passes, though it may > influence selection. this flag is used quite a bit in llvm-backend.cpp, for example: if (flag_unit_at_a_time) {

Hi Duncan, Ok, I found that even if main() does reference foo, setup() still gets chopped off and the results is the unexpected: Foo: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Bar: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Baz: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 So, while there is the issue in LTO, I still think Clang could give a warning. This is a source of buffer overflow

On Mar 15, 2009, at 7:55 AM, Nyx wrote: > > Is there a webpage documenting these function passes? Here's some: http://llvm.org/docs/WritingAnLLVMPass.html#FunctionPass You can also look in llvm/lib/Transforms/Scalar for runOnFunction () > Which ones should I run > to maximize performance? There's no right way to determine this. It depends on what you need/ want from your

Hi Devang, > > this flag is used quite a bit in llvm-backend.cpp, for example: > > > > if (flag_unit_at_a_time) { > > PM->add(createGlobalOptimizerPass()); // Optimize out > > global vars > > PM->add(createGlobalDCEPass()); // Remove unused > > fns and globs > >

I suspect my change adding --enable-shared broke you, since that configure option didn't exist before last week (r97119). SHARED_LIBRARY is not one of the variables you're supposed to be able to set on make's command line (http://llvm.org/docs/MakefileGuide.html#variables). What are you using it for? What happens if you remove it? On Tue, Mar 2, 2010 at 1:35 PM, James Williams

Hi Renato, On 08/01/13 17:16, Renato Golin wrote: > After looking at the Livermore for a while, we found the issue that was causing > LTO to produce a different result. > > Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't > reference foo. LTO finds, correctly, I don't think this is correct. At the LLVM IR level it is valid to write into bar

On Apr 16, 2008, at 1:02 PM, Duncan Sands wrote: > Hi Devang, > >> You can do inlining even when flag_unit_at_a_time is off. And one can >> enable unit-at-a-time without enabling any optimizations. The unit- >> at- >> a-time is not meant to select optimization passes, though it may >> influence selection. > > this flag is used quite a bit in

This is what I have so far: // Add optimization passes to the function passes s_pFunctionPasses->add(new llvm::TargetData(s_pModule)); s_pFunctionPasses->add(llvm::createCFGSimplificationPass()); s_pFunctionPasses->add(llvm::createPromoteMemoryToRegisterPass()); s_pFunctionPasses->add(llvm::createConstantPropagationPass());

On Thu, Jun 4, 2015 at 3:58 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > Personally, I think the right approach is to add a bool to > createGlobalDCEPass defaulting to true named something like > IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after > inlining for obvious reasons, so the default makes sense. The special case > is

After looking at the Livermore for a while, we found the issue that was causing LTO to produce a different result. Consider the code below [1]. setup() doesn't touch bar/baz, main() doesn't reference foo. LTO finds, correctly, that it can remove the setup(), but the result is different. The code is clearly wrong, but the compiler has no right to fix user's stupidity, even at that

On Apr 15, 2008, at 11:49 PM, Duncan Sands wrote: > As far as I can see flag_unit_at_a_time > is used to control whether inter-procedural/whole-module passes are > scheduled. You can do inlining even when flag_unit_at_a_time is off. And one can enable unit-at-a-time without enabling any optimizations. The unit-at- a-time is not meant to select optimization passes, though it may

In llvm-backend.cpp I see: if (optimize > 1) { if (flag_inline_trees > 1) // respect -fno-inline-functions PM->add(createFunctionInliningPass()); // Inline small functions if (flag_unit_at_a_time && !lang_hooks.flag_no_builtin()) PM->add(createSimplifyLibCallsPass()); // Library Call Optimizations if (optimize > 2)

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

Hi All, I have installed llvm-gcc4 patch to enable various llvm optimizations at -O1/-O2/-O3. This means instead of $ llvm-gcc4 --emit-llvm foo.c -o foo.bc $ opt foo.bc -o foo_optimized.bc $ llc foo_optimized.bc -o foo.o One can directly use $ llvm-gcc4 -O2 foo.c -o foo.o to get optimized foo.o - Devang + + if (optimize > 0) { + + +