search for: tokenfactored

Hi Chris, Your were totally right with your suggestion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n

Hi Dan, Thanks for commenting on this topic. See my comments in-line. ----- Ursprüngliche Mail ---- > Von: Dan Gohman <gohman at apple.com> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Mittwoch, den 30. April 2008, 21:38:26 Uhr > Betreff: Re: [LLVMdev] FoldingSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman

guys, 1)i made a mistake in my post. the said TF node was created when Selected() was called in ADDC node. 2) the source code under test short a,b; void test() { a+=b; } 3)the DAG after ADDC was seleced: Select node: 0x4977a20: ch,glue = <<Unknown Machine Node #65419>> 0x4972bd0, 0x49731d0, 0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)> Result node: 0x4977a20: ch,glue =

I have added new instructions to my target, unfortunately they are not being properly type legalized. The instructions I've added are a vector add, vector load and a vector store. Can anyone lend a hand on how to legalize them so that my target would be able to recognize them. Below is the output of llc with a -debug-only=isel. As you could see the output type for load, store, and add changes

hi Tim,guys, it was regarding splitting 16-bit ADDC to two 8-bit ADDC+ADDE. the 8-bit ADDE instruction is defined as: let Constraints="$dst=$op0",mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

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

Hi Mark, >> Sounds like your load / store address selection routine isn't working >> like what you expected. >> > > Thanks for the reply. Unfortunately, this doesn't seem to be the problem. do you handle truncating stores and extending loads? Ciao, Duncan.

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

Following up on my call schedule posting from yesterday, I am now trying to add edges from the call to the instruction before it. This seemed easiest to do in SelectionDAGBuilder but it is troublesome. A couple of questions: - How do I get the previous instruction that was translated? prior(CS.getInstruction()) in visitCall returns something invalid. When I try to call getValue on the

I see we're missing an isel pattern for add producing carry and doing a memory RMW. I'm going to see if adding that helps anything. ~Craig On Mon, Feb 27, 2017 at 8:47 PM, Nirav Davé via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yes. I'm seeing that as well. Not clear what's going on. > > In any case it looks to be unrelated to the alias analysis so barring

>> I'm trying something cunning/crazy with the stack - implementing it in a type of memory that can only be addressed via immediates. >> >> I've got this mostly working. However, I came across a problem which I've been unable to work around: lowering the IR (even without any optimisations enabled) often requires the pattern: >> >> i32 = FrameIndex

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the >

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

...oads don't cause >> SelectionDAGBuilder::getRoot() to be called. Instead, they can be >> chained together with the head of the chain being stored in >> PendingLoads. Then when something else calls >> SelectionDAGBuilder::getRoot(), the chain of volatile loads is >> TokenFactored together with the non-volatile loads. I've tried this >> out and it seems to do what I want but as I'm fairly inexperienced >> with LLVM, I'm not sure whether there's something else preventing >> this strategy from working. >> >> The reason I noticed t...

...ionDAGBuilder::visitLoad() so that volatile loads don't cause SelectionDAGBuilder::getRoot() to be called. Instead, they can be chained together with the head of the chain being stored in PendingLoads. Then when something else calls SelectionDAGBuilder::getRoot(), the chain of volatile loads is TokenFactored together with the non-volatile loads. I've tried this out and it seems to do what I want but as I'm fairly inexperienced with LLVM, I'm not sure whether there's something else preventing this strategy from working. The reason I noticed this is because I have been developing a back-...

Have you read http://llvm.org/docs/WritingAnLLVMBackend.html and http://llvm.org/docs/CodeGenerator.html ? http://llvm.org/docs/WritingAnLLVMBackend.html#instruction-selector describes how to define a store instruction. -Eli On 7/6/2017 6:51 PM, hameeza ahmed via llvm-dev wrote: > Please correct me i m stuck at this point. > > On Jul 6, 2017 5:18 PM, "hameeza ahmed"

...) so that volatile loads don't cause > SelectionDAGBuilder::getRoot() to be called. Instead, they can be > chained together with the head of the chain being stored in > PendingLoads. Then when something else calls > SelectionDAGBuilder::getRoot(), the chain of volatile loads is > TokenFactored together with the non-volatile loads. I've tried this > out and it seems to do what I want but as I'm fairly inexperienced > with LLVM, I'm not sure whether there's something else preventing > this strategy from working. > > The reason I noticed this is because I hav...

On Thursday 02 October 2008 19:32, Dan Gohman wrote: > Looking at your dump() output above, it looks like the pre-selection > loads have multiple uses, so even though you've managed to match a > larger pattern that incorporates them, they still need to exist to > satisfy some other users. Yes, I looked at that too. It looks like these other uses end up being chains to

also i further run the following command; llc -debug filer-knl_o3.ll and its output is attached here. by looking at the output can we say that legalization runs fine and the error is due to instruction selection/ pattern matching which is not yet implemented? so do i need to worry and try to correct it at this stage or should i move forward to implement instruction selection/ pattern matching?