similar to: Rerunning TailCallElim at a later stage

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be

Hi, I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder.

Hi Stefan, This looks like a bug. Thanks for catching this and writing the mailing list. Do you think you could submit a patch to fix the problem ? I understand that you can’t release your source code, but there is an easy way to generate test-cases from confidential code. If you can write a “verifier" that makes the compiler crash on an assertion then you can use bug point to reduce

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

Hi Duncan, No, it hasn't been reviewed yet. On Mon, May 13, 2013 at 8:50 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, did anything happen with this patch? > > Ciao, Duncan. > > > On 09/05/13 04:04, Akira Hatanaka wrote: > >> The following code snippet taken from StackColoring::**remapInstructions >> clears a >> mem operand if it

2017-03-31 13:46 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > > > On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <llvmdev at meinersbur.de> > wrote: >> >> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> > if you transformed >> > >> > lifetime.start(%p) >> > use %p >> >

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

Hi, I was looking into the implementation of TailRecursionElimination, and noticed that we have the constrain that if any call uses a local, even though it doesn't capture the local, it would still prohibit TCE. This contain seems unnecessary and overly limiting? Relevant code is here:

Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this mail list? Now results. Big improvement in llvm tests results from last test result sended. New regressions: Regression.Assembler.ConstantExprFold : FAIL , expected PASS Regression.CodeGen.Generic.2004-04-09-SameValueCoalescing: FAIL , expected PASS Regression.Transforms.PRE.basictest : FAIL

On 11 Dec 2012, at 21:00, Justin Holewinski wrote: > I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. > > But what is the guarantee/constraint placed on

I was trying the new feature you introduce about printing out the graphs, so I updated my version of llvm/clang/polly synchronizing them to the last version, but I get this error launching clang (also , I recently switched to MacOS X for development): $ clang not_so_simple_loop.c -O3 -Xclang -load -Xclang ${PATH_TO_POLLY_LIB}/LLVMPolly.dylib -mllvm -enable-polly-viewer -mllvm -enable-iv-rewrite

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

Caldarale, Charles R schrieb: > You have not provided us with the declaration for f(). Unless its argument is marked with the nocapture attribute, the compilation of g() cannot assume that f() has not retained a pointer to the x struct and is using it in the second call. > thanks a lot for the input. Yes, I forgot to that. The C function declaration would have been void f( struct a_b

Hi, I am planning to use LLVM for a compiler validation project that checks if the optimized version of the code is the correct translation of the unoptimized code. And I have a couple of questions. I need two pieces of information from the compiler: 1) Some kind of mapping between the structure of the unoptimized and optimized code. It seems, that can be obtained via the llvm.dbg.stoppoint

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

On 10/22/2011 08:41 AM, Marcello Maggioni wrote: > I was trying the new feature you introduce about printing out the > graphs, so I updated my version of llvm/clang/polly synchronizing them > to the last version, but I get this error launching clang (also , I > recently switched to MacOS X for development): > > $ clang not_so_simple_loop.c -O3 -Xclang -load -Xclang >