similar to: [LLVMdev] Handling of DebugLocs during CSE of SelectionDAG nodes.

On Sep 13, 2011, at 4:01 AM, Kyriakos Georgiou wrote: > I've been investigating a case with the XCore target (which doesn't use > FastISel) where the DWARF line number emitted at -O0 results in the xgdb > visiting source lines in an unexpected order. I've tracked down the > problem to the handling of DebugLocs in the selection DAG, in the getNode > method shown bellow.

On 13/09/11 17:40, Devang Patel wrote: > On Sep 13, 2011, at 4:01 AM, Kyriakos Georgiou wrote: >> I've been investigating a case with the XCore target (which doesn't use >> FastISel) where the DWARF line number emitted at -O0 results in the xgdb >> visiting source lines in an unexpected order. I've tracked down the >> problem to the handling of DebugLocs in

On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > Is there a view on which of the following approaches is better in > general when two nodes with debug locations are merged because of CSE > (either in the MachineCSE pass or because of the CSEMap in the > SelectionDAG): > > 1) Use the DebugLoc of either of the pair of nodes (chosen arbitrarily). > 2) Throw away the

On Sep 14, 2011, at 10:34 AM, Jakob Stoklund Olesen wrote: > > On Sep 14, 2011, at 7:37 AM, Richard Osborne wrote: > >> Is there a view on which of the following approaches is better in >> general when two nodes with debug locations are merged because of CSE >> (either in the MachineCSE pass or because of the CSEMap in the >> SelectionDAG): >> >>

> On May 7, 2018, at 11:29 PM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, (Resent with proper subject line) > > I recently found myself in trouble because the crash I had disappeared > with -g, so I could not debug the program. This happened because the > optimizer did not remember to consider DBG_VALUEs

Hi, (Resent with proper subject line) I recently found myself in trouble because the crash I had disappeared with -g, so I could not debug the program. This happened because the optimizer did not remember to consider DBG_VALUEs instruction so it changed its behavior, and the bug went hiding. I then started discussing this onhttps://reviews.llvm.org/D45878, and

Hi, For my research, I need to reshape the current ARM backend to support armv2a. Zero-extend half word load (ldrh) is not supported by armv2a, so I need to make the code generation to not generate ldrh instructions. I want to replace all those instances with a 32-bit load (ldr) and then and the result with 0xffff to mask out the upper bits. These are the modifications that I have made to

I am having some problems with the generated code having wrong constants in the constant pull. Adding a dump of "C" and "E" in SelectionDAG::getConstantPool I get C: ---------------------------------------------------------- %str = internal constant [12 x sbyte] c"Hello World\00" ; <[12 x sbyte]*> [#uses=1]

I think that the problem is in SelectionDAG::getConstantPool itself. Only Alignment and Offset are used in the ID. This causes false aliases. X86TargetLowering::LowerFABS should also be affected. All of its calls to getConstantPool have the same alignment and offset. Best Regards, Rafael

On Mon, 14 Aug 2006, [UTF-8] Rafael Esp?ndola wrote: > I think that the problem is in SelectionDAG::getConstantPool itself. > Only Alignment and Offset are used in the ID. This causes false > aliases. Doh. Sorry about that, I just checked in a fix. Please verify that this corrects the problem. > X86TargetLowering::LowerFABS should also be affected. All of its calls > to

When I try to run the "sammon" function of the multiv package, I always get this error message: Error in as.vector(dist(a)) : couldn't find function "dist" It happens even with example(sammon). I am running R 1.5.0 on Win98 and I have still installed R 1.4.1 but it doesn't work on the old R version with the older multiv package either. Is there a problem with the

Hi, I want to remove metadata from an instruction. Is there any way doing this in my pass? Regards, Kyriakos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130815/08200e23/attachment.html>

My (dumb?) question would be: why is llvm.assume being handled any differently than llvm.assert ? Other than one trapping and one not-trapping, they should be identical, in both cases they are giving The optimizers information, and that shouldn't be any different from being inside an "if" statement with the same condition ? --Peter Lawrence. -------------- next part --------------

Hello, while invoking opt with all possible optimization pairs I stumbled over a stack dump when doing -early-cse-memssa twice: $ clang -Xclang -disable-O0-optnone -S -o fannkuch7.ll -emit-llvm fannkuch7.c $ opt -S -o fannkuch7.ll -early-cse-memssa -early-cse-memssa fannkuch7.ll Questions: Is it illegal to call -early-cse-memssa twice? Are there any other incompatible optimization orders?

I'm working on the across the subprogram call optimization, and let's say the following llvm IR, @ng0 = internal global [2 x i32] [i32 2, i32 0], align 4 %t7 = alloca [16 x i8], align 16 %add.ptr = getelementptr inbounds i8* %t1, i64 40 %call = call i8* @handle_value(i8* %add.ptr, i32 3) #3 %arraydecay = getelementptr inbounds [8 x i8]* %t3, i64 0, i64 0 %arraydecay1 =

On Fri, Jun 10, 2016 at 9:58 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > On Jun 10, 2016, at 7:00 PM, Lawrence, Peter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Daniel, > My point is this, > > If (cond) ---- optimizer takes advantage of knowing cond == true within > the “then” part > Assert(cond)

What he said :) It also, representationally, has a related issue our current assume does in terms of figuring out the set of assumptions applied. Given an instruction, in extended SSA, because " assume" produces a value used by things, it's trivial to find the chain of assumptions you can use for it. In a straight control flow representation, it requires finding which side of the

Ok I think we have some common ground - CSE should choose the aliased pointer over the non-aliased one because we don't want the no-aliasing information to creep outwards from the inlined callsite. I'll put together a patch in the coming days and add y'all as reviewers so you get visibility. Cheers, -Neil. On Wed, Jan 22, 2020 at 4:47 PM Jeroen Dobbelaere < Jeroen.Dobbelaere at

As of llvm 3.8, the early CSE pass seems to remove llvm.assume intrinsics. Is this the expected behavior? I've attached as small-ish example of this happening in my production code. $ opt -early-cse before-early-cse.ll -S > after-early-cse.ll Note the use of the assume intrinsic indicating that the loaded value %channels equals 3. In a later pass I replace the load instruction with

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation