similar to: [LLVMdev] RFC: Constant Hoisting

> On Feb 3, 2015, at 10:20 AM, Chris Sears <chris.sears at gmail.com> wrote: > > I was using this GCC compiler comparison site. It's well done but unfortunately it's not up to date. The author Matt Godbolt said he was updating it: > > http://gcc.godbolt.org/# <http://gcc.godbolt.org/#> > > No, I do not have 3.4.1 but 3.5 is the current XCode release.

Hi Chris, If you have everything setup to test, can you generate the LLVM IR with -03 from 3.4.1 and 3.5 to be sure they match. Then we can focus on the backend. Thanks, Mehdi > On Feb 3, 2015, at 1:58 AM, Chris Sears <chris.sears at gmail.com> wrote: > > So between 3.4.1 and 3.5 since it isn't in 3.4.1 and it is in the current XCode. -------------- next part

Yes, it does seem to be a regression (and not pilot error) although I can't imagine how. I pulled a new tree and recompiled. Untouched and unpatched the bugs are there. newtst.c newtst.ll and newtst.s are attached. LLVM (http://llvm.org/): LLVM version 3.7.0svn DEBUG build with assertions. Built Feb 2 2015 (22:14:40). Default target: x86_64-apple-darwin14.1.0 Host CPU: penryn

Using Ulrik?s example data (and assuming I understand what is wanted), here is what I would do: ex.dat <- c("FName: fname1", "Fval: Fval1.name1", "Fval: ", "FName: fname2", "Fval: Fval2.name2", "FName: fname3") tst <- data.frame(x = ex.dat, stringsAsFactors=FALSE) sp <- strsplit(tst$x, ':', fixed=TRUE) chk <-

Hi, I am a newbie in R and was working on some DNA data represented as strings of A,C,T and G (also wild-character like M and X). I use the Bioconductor package in R. Currently I need to convert a string of the form "ACCTGMX" to "1223400" i.e. A is replaced by 1, C with 2, T with 3, G with 4 and any other character with a 0. I checked with 'replace' and also with a

@Don your solution does not solve Vijayan's scenario 2. I used spread and gather for that. An alternative solution to insert mising Fval - picking up with Don's newtst - is newtst <- c("FName: fname1", "Fval: Fval1.name1", "FName: fname2", "Fval: Fval2.name2", "FName: fname3", "FName: fname4", "Fval: fval4.fname4")

Hi, I am debugging private backend and faced interesting problem: sometimes spill hoisting creates double stores. (some output from -debug-only=regalloc). First hoisting: Checking redundant spills for 0 at 16r in %vreg19 [16r,144B:0)[144B,240B:1)[240B,280r:2)[296r,416B:3)[416B,456r:4)[472r,592B:5) 0 at 16r 1 at 144B-phi 2 at 240B-phi 3 at 296r 4 at 416B-phi 5 at 472r Merged to stack int: SS#0

On Jan 25, 2009, at 12:21 AM, Jon Harrop wrote: > My question is: will LLVM optimize this back into a function > containing a loop > that runs inside a single stack frame that contains the constants > "a" and "x" > or should my compiler perform this rewrite itself? The easiest way to answer this is to write the moral equivalent in C, and see if it happens

On Wednesday 28 January 2009 07:28:38 Chris Lattner wrote: > On Jan 25, 2009, at 12:21 AM, Jon Harrop wrote: > > My question is: will LLVM optimize this back into a function > > containing a loop > > that runs inside a single stack frame that contains the constants > > "a" and "x" > > or should my compiler perform this rewrite itself? > >

Daniel, Thanks a lot for the pointer, that's very helpful! I'll use that as a guide to update how we handle volatile accesses. Mind if I ask for feedback when I update the patch? Krzysztof, Thanks for the answer, that was very informative! I appreciate it! Best, Alina On Wed, Dec 20, 2017 at 5:33 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > Hi Alina, > The

Hi Krzysztof, Could I get some background info on reasoning about hoisting in the presence of volatile loads? I was looking at this testcase: test/Transforms/LICM/volatile-alias.ll Context: MemorySSA treats volatile loads as defs. I'm looking to better understand expected behavior in the presence of volatile accesses. More context: https://reviews.llvm.org/D40375. Thanks in advance, Alina

I am just considering various different designs for the code emitted by a HLVM and one alluring approach is to make all local variables immutable and replace loops with (tail) recursive functions. This makes it much easier to reason about injected code such as GC checks. However, I am concerned about the performance of the generated code. Specifically, this is likely to result in small

Hi, First, sorry in advance for pasting code like this :) I'm doing a simple optimization pass for a cs326 class project. The pass in question is LICM, and I'm getting an assertion when I try to hoist an instruction. My hoist function is below. I dont think I need that copying in there, that was just something people on the newsgroup suggested. I get the same assertion

David Peixotto <dmp <at> rice.edu> writes: > I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I rechecked this and am I actually seeing the same results as you. I think I must have made a stupid mistake in my tests before - sorry for the noise. However, I found that we have a phase ordering problem which is preventing us getting as much

Duncan Sands <baldrick <at> free.fr> writes: > > > I see the same with clang. I'm not sure why the optimizers do so much better > > when they can see that sp is a local array (the special initial values don't > > matter). > > It is the scalar replacement of aggregates pass that puts everything into > registers when sp is a local array. Yes, I

Hi Max, > The Glasgow Haskell Compiler LLVM backend is generating a lot of code which > appears to be optimised by LLVM quite poorly. The problem is demonstrated by > this C source code: if I run this at -O3 under llvm-gcc from top-of-tree on x86-64 linux then (1) it computes that g(5) is equal to 95, and main is transformed to just print 95. (2) g is transformed into code with no

Hello LLVM, To reduce the code-size cost of relocations, I'm trying to hoist GlobalValues that are used many times. A new pass hides each hoisted GV behind a BITCAST in the dominating BB. The pass then updates users with the output of the BITCAST. This pass works properly AFAICT. The problems come in instruction selection. SelectionDAGBuilder::visitBitCast() treats the BITCAST as a no-op

Hello, I'm a little confused about the 3th and 4th arguments in the registration function, explained here: http://llvm.org/releases/3.3/docs/WritingAnLLVMPass.html e.g static RegisterPass<Hello> X("hello", "Hello World Pass", false /* Only looks at CFG */, false /* Analysis Pass */); "Lastly, we

> I see the same with clang. I'm not sure why the optimizers do so much better > when they can see that sp is a local array (the special initial values don't > matter). It is the scalar replacement of aggregates pass that puts everything into registers when sp is a local array. What happens is: the tail recursion in wf is eliminated. wf is inlined into g. scalarrepl turns the

Hello. This might be a trivial question, but is it correct if the signal handler aborts the program? For example: int *normal = ADDRESS1; volatile int* ptr = ADDRESS2; int k = *ptr; // segfaults, and the signal handler calls abort() int value = *normal; // this may be UB(undefined behavior). Let's assume that normal is dereferenceable if ptr1 does not raise SEGSEGV, but accessing