Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote:> When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before optimization:\n" << *M << "\n"; > for (auto &F : *M) > FPM->run(F); > dbgs() << "Before optimization:\n" << *M << "\n"; > > I expect that output to be the same for both ORC and ORCv2. If not something is going wrong with IR optimization.Well for ORCV2 there is no change before and after. I also get this message: JIT session error: Symbols not found: { raise_error } Yes raise_error and all other extern functions are explicitly added as global symbols.> > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > What happens if you make the following modification to your setup? > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set Codegen opt level > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); >No change. Regards
On Tue, 13 Aug 2019 at 22:58, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> > On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > > > dbgs() << "Before optimization:\n" << *M << "\n"; > > for (auto &F : *M) > > FPM->run(F); > > dbgs() << "Before optimization:\n" << *M << "\n"; > > > > I expect that output to be the same for both ORC and ORCv2. If not something is going wrong with IR optimization. > > Well for ORCV2 there is no change before and after.Okay I had to put the after dump following MPM->run(*M). So now I get optimized IR.> I also get this message: > > JIT session error: Symbols not found: { raise_error } >So this must be real issue. IR is getting optimized but then codegen is failing.> Yes raise_error and all other extern functions are explicitly added as > global symbols. > > > > > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > What happens if you make the following modification to your setup? > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set Codegen opt level > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > > > No change. > > Regards
Hi Dibyendu,> What do you see if you dump the modules before/after running the pass > manager on them, like this: > > > > dbgs() << "Before optimization:\n" << *M << "\n"; > > for (auto &F : *M) > > FPM->run(F); > > dbgs() << "Before optimization:\n" << *M << "\n"; > > > > I expect that output to be the same for both ORC and ORCv2. If not > something is going wrong with IR optimization. > Well for ORCV2 there is no change before and after.What about for ORCv1? There is nothing ORCv2 specific about this code snippet, so that seems to indicate a misconfigured function pass manager, but your pass manager config (at first glance) didn't look like it was different between the two. I also get this message:> JIT session error: Symbols not found: { raise_error }Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find explicitly added symbols. To find explicitly added symbols you need to call DynamicLibrary::SearchForAddressOfSymbol instead, but unfortunately that method's behavior is not a good fit for what DynamicLibrarySearchGenerator is trying to do. There are two ways you could tackle this: (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or (2) Add the symbols up-front using the absoluteSymbols function. I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want.> CodeGen optimization seems a more likely culprit: JITTargetMachineBuilderand ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default.> > What happens if you make the following modification to your setup? > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly setCodegen opt level> auto dataLayout = JTMB->getDefaultDataLayoutForTarget();I am not sure what to make of that. What happens if you print TM->getOptLevel() right before running CodeGen? Once your have explicitly set it I would expect them to be the same for ORCv1 and ORCv2. If they're not then it's a plumbing issue. -- Lang. On Tue, Aug 13, 2019 at 2:58 PM Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> Hi Lang, > > On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > > When you say your code is not getting optimized, do you mean that IR > optimizations are not being applied, or that codegen optimizations are not > being applied? > > > > What do you see if you dump the modules before/after running the pass > manager on them, like this: > > > > dbgs() << "Before optimization:\n" << *M << "\n"; > > for (auto &F : *M) > > FPM->run(F); > > dbgs() << "Before optimization:\n" << *M << "\n"; > > > > I expect that output to be the same for both ORC and ORCv2. If not > something is going wrong with IR optimization. > > Well for ORCV2 there is no change before and after. > I also get this message: > > JIT session error: Symbols not found: { raise_error } > > Yes raise_error and all other extern functions are explicitly added as > global symbols. > > > > > CodeGen optimization seems a more likely culprit: > JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults > for their CodeGen opt-level. JITTargetMachineBuilder defaults to > CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > What happens if you make the following modification to your setup? > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set > Codegen opt level > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > > > No change. > > Regards >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190813/4b164fc7/attachment.html>
> > > Well for ORCV2 there is no change before and after. > Okay I had to put the after dump following MPM->run(*M). > So now I get optimized IR.Huh. I assumed FPM->run(F) actually ran the function passes. I may just be misunderstanding how the pass manager works. -- Lang. On Tue, Aug 13, 2019 at 3:11 PM Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> On Tue, 13 Aug 2019 at 22:58, Dibyendu Majumdar <mobile at majumdar.org.uk> > wrote: > > > > On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > > > When you say your code is not getting optimized, do you mean that IR > optimizations are not being applied, or that codegen optimizations are not > being applied? > > > > > > What do you see if you dump the modules before/after running the pass > manager on them, like this: > > > > > > dbgs() << "Before optimization:\n" << *M << "\n"; > > > for (auto &F : *M) > > > FPM->run(F); > > > dbgs() << "Before optimization:\n" << *M << "\n"; > > > > > > I expect that output to be the same for both ORC and ORCv2. If not > something is going wrong with IR optimization. > > > > Well for ORCV2 there is no change before and after. > > Okay I had to put the after dump following MPM->run(*M). > So now I get optimized IR. > > > I also get this message: > > > > JIT session error: Symbols not found: { raise_error } > > > > So this must be real issue. IR is getting optimized but then codegen is > failing. > > > Yes raise_error and all other extern functions are explicitly added as > > global symbols. > > > > > > > > CodeGen optimization seems a more likely culprit: > JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults > for their CodeGen opt-level. JITTargetMachineBuilder defaults to > CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > > > What happens if you make the following modification to your setup? > > > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set > Codegen opt level > > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > > > > > > No change. > > > > Regards >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190813/c82f5982/attachment.html>
Hi Lang, On Tue, 13 Aug 2019 at 23:26, Lang Hames <lhames at gmail.com> wrote:>> I also get this message: >> JIT session error: Symbols not found: { raise_error } > > > Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find explicitly added symbols. To find explicitly added symbols you need to call DynamicLibrary::SearchForAddressOfSymbol instead, but unfortunately that method's behavior is not a good fit for what DynamicLibrarySearchGenerator is trying to do. > > There are two ways you could tackle this: > (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or > (2) Add the symbols up-front using the absoluteSymbols function. > > I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want. >Okay I will look into this. Thank you for all the help.> > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > What happens if you make the following modification to your setup? > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set Codegen opt level > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > I am not sure what to make of that. What happens if you print TM->getOptLevel() right before running CodeGen? Once your have explicitly set it I would expect them to be the same for ORCv1 and ORCv2. If they're not then it's a plumbing issue. >I explicitly set TM->Options anyway so maybe I don't need this? Regards Dibyendu