similar to: [LLVMdev] Narrowing pointers to storage width from GPR width

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable operations.

On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently,

On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: > It looks like I need to be able to intercept GEP lowering (in > SelectionDAGLowering::visitGetElementPtr) and insert something else > other than the shifts and adds. The basic problem is that CellSPU > loads and stores on 16-byte boundaries. Consequently, the SPU backend > has to do the load or store differently

On Aug 28, 2007, at 6:15 PM, Scott Michel wrote: > On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > >> On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >>> It looks like I need to be able to intercept GEP lowering (in >>> SelectionDAGLowering::visitGetElementPtr) and insert something else >>> other than the shifts and adds. The basic problem is

Hello, I did a little experiment modifying LLVM to be able to use alias-analysis information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized

Hi. Is it possible to make gpr from raw? library(aroma) #read gpr file gpr <- GenePixData$read("gpr123.gpr", path=aroma$dataPath) # gpr -> raw raw <- as.RawData(gpr) # raw -> ma ma <- getSignal(raw, bgSubtract=FALSE) ma.norm <- clone(ma) #normalization normalizeWithinSlide(ma.norm, "s") #ma -> raw raw2 <- as.RawData(ma) I want to make gpr data from

I've got a question about how SelectionDAGBuilder treats loads. The LLVM Language Reference Manual explicitly states that the order of volatile operations may be changed relative to non-volatile operations. However, when the SelectionDAGBuilder in LLVM 3.1 encounters a volatile load, it flushes all pending loads and then chains the volatile load onto them meaning that the volatile load must

[I assume you meant to send this to the list as well, not just me.] Begin forwarded message: Date: Wed, 3 Nov 2010 14:43:54 +0000 From: Salomon Brys <salomon.brys at gmail.com> To: Török Edwin <edwintorok at gmail.com> Subject: Re: [LLVMdev] Forcing the Interpreter segfaults I have build LLVM in debug mode. Here are the informations of the segfault : memcpy() at 0x7ffff6f6581e

Steve, I had created a patch last year that does something similar to what you describe for regular loads and stores using aliasing information. I think that the last message in the thread was: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140299.html This approach has worked for me, but it is not the preferred solution going forward. The preferred solution is to keep the

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

All, The following IR is causing the assert: \begin{ll} ; ModuleID = 'x.bc' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple = "ia64-portbld-freebsd8.0" define void @__ia64_set_fast_math() nounwind { entry: tail call void asm sideeffect "mov.m

On Tue, Dec 19, 2006 at 01:31:10PM -0800, Evan Cheng wrote: > > On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > > > Hello, > > > > I did a little experiment modifying LLVM to be able to use alias- > > analysis > > information in scheduling so that independent memory operations may be > > reordered. > > I am not sure if it is a good idea to

Hello, While I was trying to cross-compile Linux OMAP kernel with llvm, I have the following error message. CC arch/arm/kernel/traps.o cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:5388: void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): Assertion `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass || OpInfo.ConstraintType ==

Is this piece of code in DAGCombiner::visitLOAD removing a dead node? 06155 if (N->use_empty()) { 06156 removeFromWorkList(N); 06157 DAG.DeleteNode(N); 06158 } If it is, is there a reason it doesn't push its operands to the work list as done in line 974-975? 00970 // If N has no uses, it is dead. Make sure to revisit all N's operands once

Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to do it for me via something like visitGetElementrPtr? On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> > >> Thanks. > >> > >> So basically then this

Hi, While profiling LLVM using my test-cases with huge MBBs, I noticed that FoldingSetNodeID operations (ComputeHash,insertion,etc) may become really inefficient for the nodes, which have very many operands. I can give you an example of what is meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB

On Dec 19, 2006, at 12:13 PM, Dan Gohman wrote: > Hello, > > I did a little experiment modifying LLVM to be able to use alias- > analysis > information in scheduling so that independent memory operations may be > reordered. I am not sure if it is a good idea to do this at scheduling time. LLVM explicitly models control flows dependencies as chain operands. This eliminated

On Sep 16, 2009, at 5:58 AM, Kenneth Uildriks wrote: >> I recently made a major reorganization of the calling-convention >> lowering code which cleared away one of the major obstacles to >> doing this within codegen. >> >> Dan > > So what was the obstacle, and how was it cleared? The biggest obstacle is that there used to be two different methods for lowering

So, I have this small test program that I figured would cause no problems but want to test all the various data types and operations with my modified sparc backend. I've been working on LLVM for about 3 days now, so this might be a problem with not knowing enough yet, so thanks for bearing with me. The code that I based my example off of is compiled to LLVM-IR from: void

I'm getting this: /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function `void llvm::SelectionDAGLowering::visitSetCC(llvm::User&, llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: ` UnsafeFPMath' undeclared (first use this function)