similar to: IR Pass Ordering Sensitivity

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: > > https://github.com/kavon/autotune > >

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? I noticed that TBAA is only run once, early on in the pass ordering for O1 through O3. My thinking is that if a pass that duplicates code is run, the analysis info may not have data for the result of the new load/stores. A solution might be

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

> 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? Yes, there are a few reasons. Undoing the CPS transformation earlier in the pipeline would mean that we are using LLVM's built-in stack. The special layout and usage of the stack in

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}

> The semantics around inlining alone are problematic enough to warrant serious hesitation. There are nicer ways to embed CPS call/return into LLVM; I just figured that there would not be much support for adding a new terminator because it would change a lot of code. Ideally we would have a block terminator like: cps call ghccc @bar (.. args ..) returnsto label %retpt Where the

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 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)

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,

(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 call; you can retrieve it with llvm.returnaddress if you need it. Unfortunately the @llvm.returnaddress intrinsic does not solve

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

> Most architectures have a call instruction which does not push anything onto the stack; e.g. on ARM, the "BL" instruction saves the return address in LR. On other architectures, you can emulate this (for example, you could lower an IR "call" to LEA+JMP on x86-64). This is similar to what I was originally thinking, since the end goal of all of this is the following

This is release_50 branch of git, sha1: f1d5723be3f9456a6b16cdf687847ac2918846de Using gcc 7.2.0 from homebrew. $ CC=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-gcc-7 CXX=/usr/local/opt/gcc/bin/x86_64-apple-darwin16.7.0-g++-7 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/Users/andy/local/llvm5 -DCMAKE_PREFIX_PATH=/Users/andy/local/llvm5 $ make VERBOSE=1 [ 92%] Linking CXX

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

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

Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm not familiar with your frontend but you might want to use -mllvm -opt-bisect-limit. On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote: Valgrind is strictly better than address sanitizer, is that right? It runs valgrind-clean: [nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind

> > > > - Dead code elimination (ADCE, BDCE) > > > Regarding BDCE: The trivialized values might indeed be irrelevant to > later calculations, but might harm the debugging experience? If BDCE > only was applied at O2 and higher, that's likely not a huge loss. > Regular DCE (meaning without the bit-tracking parts) is probably fine > for O1. > > >

Hi Everyone, We caught a report for a failed self test when using Clang 5.0 and 6.0 with -DDEBUG and -O1 (i.e., a "debug build"). The code is question is located at https://github.com/weidai11/cryptopp/blob/master/cham-simd.cpp . It is the SSSE3 code path for CHAM64. Other optimizations levels are OK for Clang. GCC, ICC and MSVC are OK. The code is valgrind, Sanitizer, Coverity and