[LLVMbugs] [Bug 8647] New: getPointerToFunction() hangs in LLVM 2.8

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Thu Nov 18 04:09:05 PST 2010


           Summary: getPointerToFunction() hangs in LLVM 2.8
           Product: new-bugs
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stephenckyle at gmail.com
                CC: llvmbugs at cs.uiuc.edu

I'm having an issue using getPointerToFunction(), where it is hanging
in rare cases.

If I use llvm::CodeGenOpt::None when calling .setOptLevel() on my
EngineBuilder, and add the following Passes to a PassManager:

PM.add(llvm::createInstructionCombiningPass()); // Clean up after IPCP & DAE
PM.add(llvm::createCFGSimplificationPass()); // Clean up after IPCP & DAE
PM.add(llvm::createScalarReplAggregatesPass()); // Break up aggregate allocas
PM.add(llvm::createInstructionCombiningPass()); // Cleanup for scalarrepl.
PM.add(llvm::createJumpThreadingPass()); // Thread jumps.
PM.add(llvm::createCFGSimplificationPass()); // Merge & remove BBs
PM.add(llvm::createInstructionCombiningPass()); // Combine silly seq's
PM.add(llvm::createReassociatePass()); // Reassociate expressions
PM.add(llvm::createMemCpyOptPass()); // Remove memcpy / form memset
PM.add(llvm::createSCCPPass()); // Constant prop with SCCP
PM.add(llvm::createDeadStoreEliminationPass()); // Delete dead stores
PM.add(llvm::createAggressiveDCEPass()); // Delete dead instructions
PM.add(llvm::createCFGSimplificationPass()); // Merge & remove BBs

(You may notice that these are just taken from
createStandardOptimizationPasses(), only with irrelevant ones

Then the attached C file is optimised and JITed within a simple test
program which parses the input C file with Clang, calls run() on the
produced Module, gets the relevant function (called LC_0x000012a0() in
this file), and JITs it with getPointerToFunction(). The attached C
was machine-generated (I've removed some extern function calls), but
for 99.999...% of cases the system can JIT any produced C code.

However, if I change llvm::CodeGenOpt::None to
llvm::CodeGenOpt::Default, then getPointerToFunction() will just hang,
unless I also remove PM.add(llvm::createFunctionInliningPass(255));...

This seems to be a regression introduced in LLVM 2.8 - the function
doesn't seem to hang in 2.7.

The easiest way to replicate this is to run:

opt -std-compile-opts bad-c.ll

on the attached bad-c.ll file. This .ll file was created using
llvm::Module.dump(), from the attached bad-c.c file.

You'll notice that if you use the opt built from LLVM 2.7, it completes, but in
LLVM 2.8, it just hangs. I was unsure of whether I could use bugpoint to reduce
this .ll file, as the problem isn't that opt crashes, just that it hangs.

Thanks for looking into this.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list