search for: guaranteedtailcallopt

I don't know if GuaranteedTailCallOpt is in anyone's plans. It might be a good idea to implement some time. I am not sure what GHC's exact needs are, though. Cameron On Jun 17, 2011, at 1:49 PM, Karel Gardas wrote: > > Hello Cameron, > > thanks a lot for your fast answer, which just makes me curious if making A...

...usttail` because the callee and caller often have >>> different signatures. >>> >>> We would like to support link time optimization in our programming >>> language, because performance is important to us. However, there is no >>> clang flag to enable the GuaranteedTailCallOpt flag, and the only way to >>> pass target options to the lto plugin currently is via an unsupported API >>> that parses those flags to static variables. >>> >> >> I assume you mean passing internal options via -mllvm through the linker? >> > > Yes...

...development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. > > Cameron > > On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > >> >> John, >> >> I've moved with patches to HEAD and unfortunately the comments about >> disabling tailcalls do not go away with this update. Pleas...

...ne another in deeply nested recursive calls. We can't use `musttail` because the callee and caller often have different signatures. We would like to support link time optimization in our programming language, because performance is important to us. However, there is no clang flag to enable the GuaranteedTailCallOpt flag, and the only way to pass target options to the lto plugin currently is via an unsupported API that parses those flags to static variables. This works on Linux, but the Mac OS linker does not actually initialize the TargetOptions that it passes as an llvm::lto::Config based on the parsed stati...

...t be fixable? > We can't use `musttail` because the callee and caller often have different > signatures. > > We would like to support link time optimization in our programming > language, because performance is important to us. However, there is no > clang flag to enable the GuaranteedTailCallOpt flag, and the only way to > pass target options to the lto plugin currently is via an unsupported API > that parses those flags to static variables. > I assume you mean passing internal options via -mllvm through the linker? > This works on Linux, but the Mac OS linker does not actua...

...lag was created. > > > We can't use `musttail` because the callee and caller often have different signatures. > > We would like to support link time optimization in our programming language, because performance is important to us. However, there is no clang flag to enable the GuaranteedTailCallOpt flag, and the only way to pass target options to the lto plugin currently is via an unsupported API that parses those flags to static variables. > > I assume you mean passing internal options via -mllvm through the linker? > > Yes that's correct, we are passing -mllvm -tailcallopt...

Happy 2011, everybody! It seems -tailcallopt prevents tailcall optimization when both caller and callee have ccc, even when it is optimized without an option -tailcallopt. Is it intended or misoptimized? In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): if (GuaranteedTailCallOpt) { if (IsTailCallConvention(CalleeCC) && CCMatch) return true; return false; } I know -tailcallopt changes calling conversion of fastcc to callee-pop. ps. I am tweaking tailcallopt on Win64. ...Takumi

...PU(llvm::sys::getHostCPUName()); TargetOptions targetOptions; targetOptions.NoFramePointerElim = true; targetOptions.LessPreciseFPMADOption = true; targetOptions.UnsafeFPMath = true; targetOptions.NoInfsFPMath = true; targetOptions.NoNaNsFPMath = true; targetOptions.GuaranteedTailCallOpt = true; builder.setTargetOptions(targetOptions); TargetMachine* tm = builder.selectTarget(); fJIT = builder.create(tm); if (!fJIT) { return false; } …. Any idea? Thanks. Stéphane Letz

...the list. --> #include "llvm/Target/TargetOptions.h" #include <iostream> extern "C" { using namespace std; void enable_tail_call_opt() { cout << "Enabling TCO" << endl; //llvm::PerformTailCallOpt = true; <-- pre-2.7 name llvm::GuaranteedTailCallOpt = true; } } </code> Compiling 3.0 (but not 2.8 or earlier) I also had to run: touch llvm-3.0.src/bindings/ocaml/llvm/Release/META.llvm to passify make install, since it tried to install metadata, but didn't have any. Trouble was that just about all test cases would cause "Stac...

I'm just trying to test HLVM with the latest SVN of LLVM and discovered that llvm::PerformTailCallOpt has disappeared from the code but it is still referred to from LangRef.html. Where did it go? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

...n Feb 18, 2010, at 2:12 AM, Jon Harrop wrote: > > I'm just trying to test HLVM with the latest SVN of LLVM and discovered that > llvm::PerformTailCallOpt has disappeared from the code but it is still > referred to from LangRef.html. > > Where did it go? It got renamed to GuaranteedTailCallOpt, to better reflect what it actually represents. --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100218/be3e2c7...

...en it is optimized without an option -tailcallopt. Sorry, I don't understand your question. What do you mean by both caller and callee have ccc? Evan > Is it intended or misoptimized? > > In X86ISelLowering.cpp:X86TargetLowering::IsEligibleForTailCallOptimization(): > > if (GuaranteedTailCallOpt) { > if (IsTailCallConvention(CalleeCC) && CCMatch) > return true; > return false; > } > > I know -tailcallopt changes calling conversion of fastcc to callee-pop. > > ps. I am tweaking tailcallopt on Win64. > > ...Takumi > ____________________...

...ch is local to each TargetMachine." Unfortunately, they don't say anything about how to fix existing source to work around this. In my application I create a JIT using ExecutionEngine::create() after initializing the native target using InitializeNativeTarget(). I also need to set the GuaranteedTailCallOpt flag beforehand. However, with LLVM 3.1 the global GuaranteedTailCallOpt flag is gone and neither ExecutionEngine::create() nor InitializeNativeTarget() accept a TargetOptions argument. Nor could I find a way to retrieve and change the target options later. Is that an oversight, or is there so...

...t; > TargetOptions targetOptions; > targetOptions.NoFramePointerElim = true; > targetOptions.LessPreciseFPMADOption = true; > targetOptions.UnsafeFPMath = true; > targetOptions.NoInfsFPMath = true; > targetOptions.NoNaNsFPMath = true; > targetOptions.GuaranteedTailCallOpt = true; > > builder.setTargetOptions(targetOptions); > > TargetMachine* tm = builder.selectTarget(); > > fJIT = builder.create(tm); > if (!fJIT) { > return false; > } > …. > > Any idea? It's hard to say much without seeing the...

They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative about when to use tail calls, and doesn't support GuaranteedTailCallOpt, which might be necessary for GHC. Cameron On Jun 17, 2011, at 1:31 PM, Karel Gardas wrote: > > John, > > I've moved with patches to HEAD and unfortunately the comments about > disabling tailcalls do not go away with this update. Please see > ARMTargetLowering::LowerCa...

John, I've moved with patches to HEAD and unfortunately the comments about disabling tailcalls do not go away with this update. Please see ARMTargetLowering::LowerCall in lib/Target/ARM/ARMISelLowering.cpp line 1208 and later. It looks like man can use -arm-tail-calls, but one never knows how good it is since the comment tells it clearly: // Temporarily disable tail calls so things

...Options targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInfsFPMath = true; >> targetOptions.NoNaNsFPMath = true; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTargetOptions(targetOptions); >> >> TargetMachine* tm = builder.selectTarget(); >> >> fJIT = builder.create(tm); >> if (!fJIT) { >> return false; >> } >> …. >> >> Any idea? &...

...Options targetOptions; >> targetOptions.NoFramePointerElim = true; >> targetOptions.LessPreciseFPMADOption = true; >> targetOptions.UnsafeFPMath = true; >> targetOptions.NoInfsFPMath = true; >> targetOptions.NoNaNsFPMath = true; >> targetOptions.GuaranteedTailCallOpt = true; >> >> builder.setTargetOptions(targetOptions); >> >> TargetMachine* tm = builder.selectTarget(); >> >> fJIT = builder.create(tm); >> if (!fJIT) { >> return false; >> } >> .. >> >> Any idea? &...

...jectFileELFin libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) typeinfo for llvm::TargetLoweringObjectFileMachOin libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) typeinfo for llvm::TargetLoweringObjectFileCOFFin libLLVMCodeGen.a(TargetLoweringObjectFileImpl.cpp.o) "llvm::GuaranteedTailCallOpt", referenced from: __ZN4llvm21GuaranteedTailCallOptE$non_lazy_ptr in libLLVMCodeGen.a(Analysis.cpp.o) "llvm::TargetLoweringObjectFile::SectionForGlobal(llvm::GlobalValue const*, llvm::SectionKind, llvm::Mangler*, llvm::TargetMachine const&) const", referenced from:...

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey