search for: farvardin

On Fri, Apr 14, 2017 at 6:12 AM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 04/14/2017 08:03 AM, Kavon Farvardin via llvm-dev wrote: > >> Thanks for the explanation Sanjoy! >> >> Another question I have is: are there are any passes that invalidate or >> make the TBAA analysis information less precise? >> > > Some transformation drop TBAA information when they might inval...

...analysis info may not have data for the result of the new load/stores. A solution might be to add -tbaa after each -basicaa. ~kavon > On Apr 14, 2017, at 4:45 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Kavon, > > On April 13, 2017 at 11:31:17 AM, Kavon Farvardin via llvm-dev > (llvm-dev at lists.llvm.org) wrote: >> I'm trying to work with Type Based Alias Analysis (TBAA). Here's the example program >> I'm working with: >> >> ;;;;;;;;;;;;;;;;;;;;;; >> >> define void @foo(i64* %a, i64* %b, i64 %x, i64 %y)...

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI,

Hi, I'm trying to work with Type Based Alias Analysis (TBAA). Here's the example program I'm working with: ;;;;;;;;;;;;;;;;;;;;;; define void @foo(i64* %a, i64* %b, i64 %x, i64 %y) { store i64 %x, i64* %a, !tbaa !2 ; write to stack store i64 %y, i64* %b, !tbaa !3 ; write to heap ret void } !1 = !{!"root"} !2 = !{!"stack", !1} !3 = !{!"heap", !1}

...wrote: > > Hi Kavon, > > Is there a reason you can't use the algorithm from the paper "A Correspondence between Continuation Passing Style and Static Single Assignment Form" to convert your IR to LLVM's SSA IR? > > -Manuel > > On 2017-04-17 17:30, Kavon Farvardin via llvm-dev wrote: >> Summary >> ======= >> There is a need for dedicated continuation-passing style (CPS) calls in LLVM to >> support functional languages. Herein I describe the problem and propose a >> solution. Feedback and/or tips are greatly appreciated, as our g...

...would there be more support for a version of this terminator (whether as an intrinsic or not) instead of what I was proposing earlier? ~kavon > On Apr 18, 2017, at 7:24 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 04/17/2017 08:30 AM, Kavon Farvardin via llvm-dev wrote: >> Summary >> ======= >> >> There is a need for dedicated continuation-passing style (CPS) calls in LLVM to >> support functional languages. Herein I describe the problem and propose a >> solution. Feedback and/or tips are greatly appreciated...

...C, since the workaround would penalize general function calls. This is why support is necessary for GHC (and related compilers) in order to use LLVM effectively. ~kavon > On Apr 17, 2017, at 7:47 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 4/17/2017 8:30 AM, Kavon Farvardin via llvm-dev wrote: >> Summary >> ======= >> >> There is a need for dedicated continuation-passing style (CPS) calls in LLVM to >> support functional languages. Herein I describe the problem and propose a >> solution. Feedback and/or tips are greatly appreciated...

Hi, I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2)

Summary ======= There is a need for dedicated continuation-passing style (CPS) calls in LLVM to support functional languages. Herein I describe the problem and propose a solution. Feedback and/or tips are greatly appreciated, as our goal is to implement these changes so they can be merged into LLVM trunk. Problem ======= Implementations of functional languages like Haskell and ML (e.g., GHC

...e the non-tail call are dead, as they have been copied to the GHC stack frame if they were live. If you have a particular example in mind that would be great. ~kavon > On Apr 18, 2017, at 2:32 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > > On 4/17/2017 3:52 PM, Kavon Farvardin wrote: >> (Sorry for the 2nd email Eli, I forgot to reply-all). >> >>> I'm not following how explicitly representing the return address of a call in the IR before isel actually solves any relevant issue. We already pass the return address implicitly as an argument to every...

On Sat, Oct 14, 2017 at 10:58:17PM -0500, Kavon Farvardin via llvm-dev wrote: > > something simpler will do, IMHO. Happy to discuss this further if > > folks are in California next week :) > > Yes, I'll be in California next week, let's chat! > > We could make use of the autotuner I'm currently building: > > ht...

On Sat, Oct 14, 2017 at 11:05 AM, John Regehr via llvm-dev <llvm-dev at lists.llvm.org> wrote: > These are definitely LLVM bugs. It would be best to report reduced test > cases against top of tree. > > We should have some automated infrastructure for finding these too... > > John > Zhendong & friends generally do that (and reported many bugs :) I tried that myself,

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

Hi all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar