search for: tokenfactor

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 pending loads, they can be combin...

...ngSetNodeID operations inefficiency > > > On Apr 28, 2008, at 6:21 AM, Roman Levenstein wrote: > > > 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 > > SelectionDAGLowerin...

...0x4972bd0: <multiple use> 0x49731d0: i32 = TargetGlobalAddress<i16* @a> 0 0x4976c20: <multiple use> 0x49606f0: <multiple use> 0x49737d0: <multiple use> 0x4976c20: <multiple use> 0x4976e20: <multiple use> 0x49730d0: ch = TokenFactor 0x49606f0, 0x49737d0:1, 0x4976c20:1, 0x4976e20:1 0x4977a20: ch,glue = addcmr 0x4972bd0, 0x49731d0, 0x4976c20, 0x49730d0<Mem:LD1[@a](align=2)> 0x4972bd0: i8 = Register %noreg 0x4976f20: i32 = TargetGlobalAddress<i16* @a> + 1 0x4977a20: <multiple use> 0x4972b...

...47f0: i32 = FrameIndex<2> 0x3ea45e0: <multiple use> 0x3ea48f8: v4i32,ch = load 0x3e7e2f0, 0x3ea47f0, 0x3ea45e0<LD16[%b](align=4)> [ORD=6] 0x3ea4e20: i32 = Register %R11 0x3ea46e8: <multiple use> 0x3ea48f8: <multiple use> 0x3ea4c10: ch = TokenFactor 0x3ea46e8:1, 0x3ea48f8:1 [ORD=8] 0x3ea46e8: <multiple use> 0x3ea48f8: <multiple use> 0x3ea4a00: v4i32 = add 0x3ea46e8, 0x3ea48f8 [ORD=7] 0x3ea4b08: i32 = FrameIndex<0> 0x3ea45e0: <multiple use> 0x3ea4d18: ch = store 0x3ea4c10, 0x3ea4a...

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

...ch,glue = CopyFromReg t4:1, Register:i64 %reg2, t4:1 t8: i64,ch,glue = CopyFromReg t6:1, Register:i64 %reg3, t6:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1, t4 t15: ch = CopyToReg t0, Register:i64 %vreg2, t8 t26: ch = TokenFactor t11, t13, t15, t2:1, t4:1, t6:1, t8:1 t16: i64 = sdiv t2, t4 Before legalization, there is a single sdiv node. After legalization, this has been expanded to a call sequence: t0: ch = EntryToken t2: i64,ch,glue = CopyFromReg t0, Register:i64 %reg0 t4: i64,ch,glue = CopyFromReg t2:1, Re...

...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 with tens of thousends of instructions, there is a TokenFactor node N that has ... 3200 operands! (These operands are PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the TokenFactor node by SelectionDAGLowering::getRoot called from the SelectionDAGLowering::visitStore). During the code selection phase, the SelectionDAG::...

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 causing miscompiles because stores that should be scheduled before the load end up scheduled after the load (but before the conversion operation, because the conversion o...

...was translated? prior(CS.getInstruction()) in visitCall returns something invalid. When I try to call getValue on the returned Instruction it blows up. I really need the SDValue produced as a result of translating that last instruction. Is there some other way to get it? - Can a TokenFactor node take a non-chain input? Consider: r1 = load ... r2 = add r3 = call The call will naturally take the chain input from the load but I also want to add a dependence from the add to the call. I was going to do something like this: Chain = TokenFactor(load chain, r2...

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 > SelectionDAGLowering::visitStore So, if I now detect in the getRoot that there are more than let's say 64 nodes in the PendingLoads queue, what should I do? - Can I take only 64 of them and forget about the rest by ignoring them? -...

...lt;-4>, Constant:i64<-5>, Constant:i64<-6>, Constant:i64<-7> t33: v8i64 = add t24, t32 t35: ch = CopyToReg t0, Register:v8i64 %vreg17, t33 t37: ch = CopyToReg t0, Register:i64 %vreg117, Constant:i64<0> t39: ch = TokenFactor t18, t35, t37 t40: ch = br t39, BasicBlock:ch<vector.body25 0x1d07660> However, when using the mips64 back end (subtarget) we get this correct selection DAG: (From 201_LoopVectorize/25_GOOD_map/NEW/6/1/NEW/Mips64/STDerr_llc_mips64) Initial selection DAG: BB#...

...provided that isVolatile() is false. If the selection DAG looks like: | | LD1 LD2 ^ ^ | | \ / add ^ | \ / ST and the chain like: LD1 LD2 ^ ^ | | \ / TokenFactor ^ | ST then the add instruction is selected. However, if operand 1 of the add is a volatile load, then the chain looks like: LD1 ^ | LD2Volatile | ST In this case the add instruction cannot be selected. The operator is commutative, so ins...

...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 bac...

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 h...

...bove, 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 TokenFactor nodes that don't go anywhere. They're really, truly, dead. Who is supposed to clean those up? -Dave

...lt;0x4452448>)(dereferenceable)> t0, GlobalAddress:i64<[65 x i32]* @b> 0, undef:i64 t6: v64i32,ch = load<LD256[bitcast ([65 x i32]* @c to <64 x i32>*)](align=16)(tbaa=<0x4452448>)(dereferenceable)> t0, GlobalAddress:i64<[65 x i32]* @c> 0, undef:i64 t9: ch = TokenFactor t4:1, t6:1 t7: v64i32 = add t6, t4 t10: ch = store<ST256[bitcast ([65 x i32]* @a to <64 x i32>*)](align=16)(tbaa=<0x4452448>)> t9, t7, GlobalAddress:i64<[65 x i32]* @a> 0, undef:i64 Combining: t10: ch = store<ST256[bitcast ([65 x i32]* @a to <64 x i32>*)](a...