similar to: [LLVMdev] Question on getLoad() and its parameters

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

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

Yes, changing parameters will create a new Node, but is there some way I can force a new node with the same parameters? -Joe On Sat, Dec 1, 2012 at 10:57 PM, Triple Yang <triple.yang at gmail.com> wrote: > Hi, Joseph, I guess getLoad() will either search an existed SDValue > *OR* create a new one for a non-existed one depending on real > parameters. > > Since you use

Hi, Joseph, I guess getLoad() will either search an existed SDValue *OR* create a new one for a non-existed one depending on real parameters. Since you use exactly the same attributes dupVal/dupNode have, no doubt getLoad() return the old one. I am not sure it's *volatile* that let you get a new result, you might want to try change some other parameters and check what it turns out. Regards.

I am writing a target for an odd cisc-like architecture which has no support for keeping most values in registers. As such, memory-memory operations are needed, but for isel to generate a memory-memory the pattern must be of the form (store (op (load) (load))). Let's use a simple example to show how this can be problematic: %0 = load i32* %a.addr, align 4 store i32 %0, i32* %other, align

Hi, Joe. I am sorry I did not catch your point. Can you provide more details? Since SDValue/SDNode can be used multiple times, why would you want to create two identical objects instead of reference to the same one? 2012/12/2 Joseph Pusdesris <joe at pusdesris.com>: > Yes, changing parameters will create a new Node, but is there some way I can > force a new node with the same

Hi: This is my first patch submission. Hopefully, this is the proper the protocol. Attached is a patch for the llc ARM backend: Added mechanism to generate switch table in a data section rather than having it interleaved with the code. This is controlled by command line flags and off by default. Also, tried to document and improve the code where I modified it. Robert -------------- next part

I'll give that a shot, thanks! -Joe On Sun, Dec 2, 2012 at 12:06 PM, Triple Yang <triple.yang at gmail.com> wrote: > OK, I get it. > > The essence of this problem is that a node can be covered exactly and > just once but its result can be referred multiple times for a tree > pattern matching isel. So to duplicate a load node (only if we can!) > is convenient to

So I think I have made some progress. SDValue dupVal = consumer->getOperand(OpNo); LoadSDNode *dupNode = (LoadSDNode*) dupVal.getNode(); SDValue newLoad = CurDAG->getLoad(dupVal.getValueType(), dupVal.getDebugLoc(), dupVal.getOperand(0), dupVal.getOperand(1), dupNode->getPointerInfo(),

OK, I get it. The essence of this problem is that a node can be covered exactly and just once but its result can be referred multiple times for a tree pattern matching isel. So to duplicate a load node (only if we can!) is convenient to conquer that case. The truth is, in pattern (add (load) (load)), source operands are memory addresses, and thus it can be treated as (addmm address,

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

Hi list: I have been trying to get my feet wet with the ARM backend. As a warmup exercise I wanted to be able to move jumptables especially large ones out of the code section. Currently the idiom for jump tables loooks like this // .set PCRELV0, (.LJTI9_0_0-(.LPCRELL0+8)) // .LPCRELL0: // add r3, pc, #PCRELV0 // ldr pc, [r3, +r0, lsl #2] // .LJTI9_0_0: //

Evan: Sorry for the late follow up, I was out of town last week. Enclosed please find the updated patch including all your suggestions and a dejagnus test. Robert On Thu, Jun 11, 2009 at 2:27 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Jun 8, 2009, at 2:42 PM, robert muth wrote: > > > On Sun, Jun 7, 2009 at 11:53 PM, Evan Cheng <evan.cheng at apple.com>

Hi Dan, > It looks like the best way to do this is to visit the handful of > places in legalize that create loads from constant pools and > add alignment parameters to the getLoad/getExtLoad calls. > > If you move the handling of Alignment==0 out of ScheduleDAGEmit.cpp > and into SelectionDAG::getConstantPool, you can then have legalize > read the alignment from the node,

Hi, > * There are still a variety of places in SelectionDAG creation that > don't preserve SVOperand/SVOffset (as well as alignment and > volatile). > > These places need to be found and fixed. This is pretty straight- > forward, > and the places that need changing can be found by inserting some > strategic assert(SVOperand)'s. I've seen at least one

Yes, this is very helpful! Thank you! How does this work when exiting a variable's liveness range? Will it automatically know to free the stack slot for reuse? -Joe On Sat, Nov 24, 2012 at 12:23 PM, Steve Montgomery < stephen.montgomery3 at btinternet.com> wrote: > Sorry, forgot to Reply-All. > > Begin forwarded message: > > *From: *Steve Montgomery

Sorry, forgot to Reply-All. Begin forwarded message: > From: Steve Montgomery <stephen.montgomery3 at btinternet.com> > Subject: Re: [LLVMdev] Prevention register promotion at the isel codegen phase > Date: 24 November 2012 17:09:58 GMT > To: Joseph Pusdesris <joe at pusdesris.com> > > I had a similar problem trying to implement reg-mem operations. The solution I

Kalle: Your patch is similar to what I'd coded (and am testing, which means a couple of hours before I consider committing). Other than cosmetic changes and changing 'NULL' to '0' (it's an integer list, after all). This patch now causes new problems in the CellSPU backend (more stqd's and lqd's), so I have to investigate those before committing the patch.

Kalle Raiskila <kalle.raiskila at nokia.com> writes: > Looks like a bug to me. xshw (extend signed half-word(16bits) to > word(32bits)) takes a v8i16 and produces a v4i32. This has likely gone > unnoticed as there is only one type of vector register class (i.e. > VECREG) that is used for all vectors. > > Nice catch :) Are there more of these? I don't know. I stopped

I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get