similar to: [LLVMdev] Proposal: Add a guaranteed tail call marker

r287955 seems like it might be related. -- Sean Silva On Sat, Nov 26, 2016 at 4:06 PM, Sean Silva <chisophugis at gmail.com> wrote: > This sounds buggy to me. What pass is doing this? > > -- Sean Silva > > On Thu, Nov 24, 2016 at 5:39 AM, Carlo Kok via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> I've got some calls like: >>

Hi sorta piggybacking on the other thread. I am looking for some feedback on how to implement the following idea in llvm. The really short version of the idea is this: * I want to alloca a field (record/struct), so that its size is an even multiple of 64 bytes. [^1] * This allocaed field will be exclusively used as an argument to functions * llvm should be aware of the extra bytes and should

Jon Harrop wrote: > I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows > so I think TCO isn't working. Have there been any obvious changes that would > cause this? FWIW, Pure uses TCO as well and that works fine with LLVM 2.8, both with the JIT and with statically compiled code, at least on x86_64. -- Dr. Albert Gr"af Dept. of Music-Informatics,

I just upgraded HLVM from LLVM 2.7 to 2.8 and started seeing stack overflows so I think TCO isn't working. Have there been any obvious changes that would cause this? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com

On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > On Monday 04 January 2010 01:12:55 Simon Harris wrote: >> I'm investigating "improving" the TCO facilities in LLVM to provide for >> "hard" tail calls. Specifically, this would involve extending the existing >> implementation to discard the stack frame for the caller before executing >> the callee. I

On Monday 04 January 2010 05:16:40 Jeffrey Yasskin wrote: > On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > LLVM's TCO already handles mutual recursion. > > Only for fastcc functions Yes. > compiled with -tailcallopt, right? If you use the compiler, yes. > http://llvm.org/docs/CodeGenerator.html#tailcallopt > > I believe

On Monday 04 January 2010 03:33:06 Simon Harris wrote: > On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > > I am certainly interested in tail calls because my HLVM project relies > > upon LLVM's tail call elimination. However, I do not understand what tail > > calls LLVM is not currently eliminating that you plan to eliminate? > > Mutual recursion for a start: >

I'm investigating "improving" the TCO facilities in LLVM to provide for "hard" tail calls. Specifically, this would involve extending the existing implementation to discard the stack frame for the caller before executing the callee. I would then like to extend this further by performing hard tail calls on _all_ returning calls that no longer require the stack frame. A

On Sun, Jan 3, 2010 at 10:50 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > On Monday 04 January 2010 03:33:06 Simon Harris wrote: >> On 04/01/2010, at 3:01 PM, Jon Harrop wrote: >> > I am certainly interested in tail calls because my HLVM project relies >> > upon LLVM's tail call elimination. However, I do not understand what tail >> > calls LLVM

On Friday 05 February 2010 23:35:15 Evan Cheng wrote: > Does anyone actually using it? Yes, many LLVM-based projects rely upon TCO to work correctly. > I'd prefer to just remove it to clean up the implementation if no one has > any objections. Are you saying that you want to remove LLVM's working TCO and replace it with something that is faster but broken? I think you may

On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: >> Does anyone actually using it? > > Yes, many LLVM-based projects rely upon TCO to work correctly. Ok, that's all I need to know. > >> I'd prefer to just remove it to clean up the implementation if no one has >> any objections. > > Are you

On Tuesday 24 February 2009 22:19:27 Arnold Schwaighofer wrote: > What i was trying to say is that if you have > > i32 a() { > %1 = tailcall b() > ret %1 > } > > > i32 b() { > %1 = tailcall c() > ret %1 > } > > i32 c() { > %1 = tailcall d() > ret %1 > } > > i32 d() { > ret i32 5 > } > > only d() will actually

On Nov 13, 2009, at 9:07 AM, Jon Harrop wrote: > > I'll try removing the noalias and seeing if that fixes it. If so, I'll file a > bug report. Which part of LLVM would this be a bug in if things like noalias > and noreturn inhibit TCO when they shouldn't? CodeGen. I looked at noalias, and it was indeed a bug. This is now fixed on trunk in r88672. Noreturn is a

On Monday 04 January 2010 01:12:55 Simon Harris wrote: > I'm investigating "improving" the TCO facilities in LLVM to provide for > "hard" tail calls. Specifically, this would involve extending the existing > implementation to discard the stack frame for the caller before executing > the callee. I would then like to extend this further by performing hard >

Dear R-Help, I am trying to compute a new variable, let's call it "target cannon orientation (tco)" based conditionally on old variables, "TargetColor," "CannonOriB," and "CannonOriR." For every case in the data set, if TargetColor is "B" then I want tco to equal the value for that case of CannonOirB, else CannonOriR. I've tried writing

I've got some calls like: musttail call void bitcast (i32 (i32, i8*, %Type*)* @MyMethod to void (i32, i8*)*)(i32 %0, i8* %1) ret void Into something like: %8 = tail call i32 @MyMethod(i32 %0, i8* %1, %Type* null) ret void I realize I'm losing a parameter there, but this is an interface jump trick I use and relies on the end code being a 'jmp' (x86). I realize i can probably

On Friday 13 November 2009 16:26:01 Chris Lattner wrote: > On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: > >> Point 4 is the one that caused me trouble for some time. > >> Unfortunately > >> it causes a bad interaction with the optimiser, specifically the > >> 'simplifycfg' pass. What seems to happen is that since the function > >> you are

Hello! I thought this was a mistake, sorry. So I created the shared directories and defined which groups can access this directory and includes the users in the defined group. However, the user defined in the group cannot access the directory, gives access denied. Take a look at the settings, if you can give me a direction of where my error is. # smb.conf [SHARE] comment = SHARE path =

On Wed, Jul 31, 2013 at 11:55 PM, Travis Cross <tc at travislists.com> wrote: > On 2013-07-30 22:11, Eli Bendersky wrote: > > we've published an initial version of the PNaCl bitcode reference > > manual online - > > http://www.chromium.org/nativeclient/pnacl/bitcode-abi. The PNaCl > > bitcode is a restricted subset of LLVM IR. > > > > Any comments

Evan Cheng wrote: > As far as I can tell only PPC and X86 targets are supporting this option. Does anyone actually using it? I'd prefer to just remove it to clean up the implementation if no one has any objections. Don't know whether that is the same, but my Pure compiler sets llvm::PerformTailCallOpt. Pure needs TCO because it doesn't have any built-in looping constructs. In