similar to: [LLVMdev] Extending LLVM for high-level types

Alexandre Cossette wrote: > Hi all, > > I'm designing a programming language named C³ (or C3). I'm already using LLVM as a back-end for my prototype compiler and it's wonderful to use. Thanks for such a great system! > > I now have more ambitious goals and I would like to use the LLVM IR as my internal C³ IR. Absolutely not. In short, LLVM is its own language. You

On 01/13/2011 03:46 AM, Nick Lewycky wrote: > Absolutely not. > > In short, LLVM is its own language. You don't need to extend LLVM IR to > support your programming language any more than you need to extend x86 > processors to support it. > > There's the burden of having that support. For starters LLVM's types are > purely based on the storage that they back.

Hi everyone, I am currently testing out a combination of IR->IR passes with opt to benchmark how they affect performance. The source code works fine if simply use the clang (-O0/-O3) to directly compile to object files and link them. However, when I use opt with a select set of passes and then use llc to compile them to binary, the compiled binary is wrong. That makes me wonder if there are

Hi all, I am trying to see how single llvm optimizations work by running them one by one with opt and looking how the IR changes.Since I was interested in seeing how constant propagation was working I tried to run opt on the Sparse Conditional Constant Propagation, however by passing as argument -S -sccp -die it does not change anything in the output IR code. I attached the file with the source

On Wed, Mar 1, 2017 at 12:53 PM, John Criswell via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/1/17 2:54 PM, Peizhao Ou via llvm-dev wrote: > > Hi everyone, > > I am currently testing out a combination of IR->IR passes with opt to > benchmark how they affect performance. The source code works fine if simply > use the clang (-O0/-O3) to directly compile to

The current gvn equality propagation is not powerful enough to get this because it doesn't try to infer values in predicates based on other predicates, so it never realizes a>b -> a !=b in a useful way. It otherwise would get this On Thu, Jun 30, 2016, 7:41 PM Sean Silva <chisophugis at gmail.com> wrote: > On Thu, Jun 30, 2016 at 6:45 PM, Daniel Berlin via llvm-dev <

This compiler does not have mem-SSA, as far as I know, only few pass can propagate value along memory. You need to promote those local variable into register first before sccp is invoked. e.g1. opt a.ll -basicaa -gvn -sccp -S eg.2. opt a.ll -sroa -sccp -S On 4/16/13 12:37 PM, Niko Zarzani wrote: > Hi all, > > I am trying to see how single llvm optimizations work by running them

Does LLVM hoist bounds checks out of inner loops? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

(and sys::cas_flag that STATISTIC uses is a uint32 ...) On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > Okay, dumb question: > Are you really getting negative numbers in the second column? > > 526,766 -136 mem2reg # PHI nodes inserted > > http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html >

Clang is currently missing some low-hanging performance and code size opportunities when receiving function parameters. For most scalar parameters, Clang typically emits an alloca and stores the LLVM SSA argument value into the alloca to initialize it. With optimizations, this initialization is often removed, but it stays behind in debug builds and when the user takes the address of a parameter (

I did gathered aggregate statistics reported by “-stats” over the ~400 test files. The following table summarizes the impact. The first column is the sum where the new analysis is enabled, the second column is the delta from baseline where no CFL alias analysis is performed. I am not experienced enough to know which of these are “good” or “bad” indicators. —david 72,250 685 SLP

So, there are two primary ideas behind SSA form management in the loop optimizers of LLVM: - Require LCSSA form input, leverage its (very powerful) guarantees to simplify maintaining SSA form, and also maintain LCSSA form. - Don't bother with LCSSA form input, assume the worst, and use powerful incremental SSA formation utilities built on SSAUpdater to form SSA on demand when needed. (Note,

Michael Spencer via llvm-dev <llvm-dev at lists.llvm.org> writes: > I've recently implemented profile guided section layout in llvm + lld using > the Call-Chain Clustering (C³) heuristic from > https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf > . In the programs I've tested it on I've gotten from 0% to 5% performance > improvement over

[ sorry for the late reply ] Patrick Meredith <pmeredit at uiuc.edu> wrote: > All register uses are SSA. Memory is not in SSA. The mem2reg pass > which promotes stack variables to registers effectively converts non- > SSA to SSA. There was a reg2mem pass, written by Andrew Lenharth, I'm > not sure if it's still being maintained. What is the difference between

On Tue, Apr 10, 2018 at 10:28 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 4/9/2018 8:19 PM, Jeehoon Kang via llvm-dev wrote: > > Dear llvm-dev, > > > Hi! We're collecting mis-compilation bugs in gvn and mem2reg since > 3.7.1. Specifically, We're interested in bugs in the following files: > > llvm/lib/Transforms/Scalar/GVN.cpp

On Nov 30, 2007, at 20:59, Jon Harrop wrote: > Does LLVM hoist bounds checks out of inner loops? In practice, LLVM is frequently going to have conservative behaviors which will prevent hoisting the explicit bounds checks your front-end must generate. Specifically, LLVM must use alias analysis to disprove the hypothesis that the array length variable is updated by the body of the loop.

Hi, Silly question from an LLVM newbie: the LLVM LRM say that the bytecode is "is an SSA based representation". Indeed, my experience with llvm-gcc is that the generated code is not necessarily SSA, while the one given by "llvm-gcc -O1" is. Is this assumption correct? Is there a non-SSA to SSA translator available? Thanks, -- Matthieu

So - here's a really modest proposal: Based on Renato's suggestion, there is a way to associate arbitrary annotation data with any LLVM type. So what I would propose as a first step is to simply replace (or perhaps supplement) the current llvm.gcroot() feature with a type annotation. That is, LLVM would only support roots that are allocas, just it does today. The backend code would not

Dear llvm-dev, Hi! We're collecting mis-compilation bugs in gvn and mem2reg since 3.7.1. Specifically, We're interested in bugs in the following files: llvm/lib/Transforms/Scalar/GVN.cpp llvm/lib/Transforms/Utils/PromoteMemoryToRegister.cpp We checked all reports in the LLVM bugzilla (https://bugs.llvm.org/), so I'd like to ask if you know any such a bug that is not reported in

Hi, I am emitting llvm bit code using llvm-gcc -c -emit-llvm -O0 -o test.bc test.c and then optimizing it with opt -O3 -print-module test.bc in order to obtain a dump of generated IR. The resulting code has Phi nodes and is perhaps in SSA form. I want to undo the SSA form while retaining all the other optimizations. Is mem2reg the right optimization to be added after -O3, i.e., opt -O3