search for: hasoneus

> I am not sure how best to fix this. If possible, InstCombine's canonicalization shouldn't hide arithmetic progressions behind bit masks. At least, it seems these transformations should be disabled unless (X >> C).hasOneUse(). They aren't exactly optimizations. > > This: > >  %div = lshr i32 %a, 2 >  store i32 %div, i32* %p, align 4, !tbaa !0 >  %add = shl nuw nsw i32 %div, 1 > > is better than this: > >  %div = lshr i32 %a, 2 >  store i32 %div, i32* %p, align 4, !tbaa !0 >  %0...

...obal i16 0, align 2 @bar = common global i16 0, align 2 define void @x() nounwind { %1 = load i16* @bar %2 = load i16* @foo %3 = add i16 %2, %1 store i16 %3, i16* @foo ret void } In the DAG matching code generated from the .td file there is : if (N1.getOpcode() == ISD::ADD && N1.hasOneUse()) { SDValue N10 = N1.getOperand(0); if (N10.getOpcode() == ISD::LOAD && N10.hasOneUse() && IsLegalAndProfitableToFold(N10.getNode(), N1.getNode(), N.getNode()) && (Chain.getNode() == N10.getNode() || IsChainCompatible(Chain.getNode(),...

...< rafael.espindola at gmail.com> wrote: > > I am not sure how best to fix this. If possible, InstCombine's > canonicalization shouldn't hide arithmetic progressions behind bit masks. > At least, it seems these transformations should be disabled unless (X >> > C).hasOneUse(). They aren't exactly optimizations. > > > > This: > > > > %div = lshr i32 %a, 2 > > store i32 %div, i32* %p, align 4, !tbaa !0 > > %add = shl nuw nsw i32 %div, 1 > > > > is better than this: > > > > %div = lshr i32 %a, 2 > &g...

> > Instead of adding the operands to a list, erase the instruction and add them to the worklist wouldn’t be probably faster something like: > > if (Instruction *Used = dyn_cast<Instruction>(*OI)) > if (Used->hasOneUse()) > WorkList.insert(Used); > > If it has one use is going to be the instruction we are going to remove anyway, right? I don’t think this is strictly true, but someone correct me if I’m wrong: if you have %y = add i32 %x, %x %x will have two uses, but it will have zero if %y is de...

Hi Daniel, I finally read the proposal. I have a couple of comments that re-enforce what I was thinking initially: it is too early IMHO to develop a full tablegen backend for this. I believe we still miss ways to represent things that matters (see my comments below) and I am afraid we still don't know all that needs to be represented. > It can reach across basic blocks when it's safe

...rivial arithmetic expressions like 'x+x' from scalar evolution. I am not sure how best to fix this. If possible, InstCombine's canonicalization shouldn't hide arithmetic progressions behind bit masks. At least, it seems these transformations should be disabled unless (X >> C).hasOneUse(). They aren't exactly optimizations. This: %div = lshr i32 %a, 2 store i32 %div, i32* %p, align 4, !tbaa !0 %add = shl nuw nsw i32 %div, 1 is better than this: %div = lshr i32 %a, 2 store i32 %div, i32* %p, align 4, !tbaa !0 %0 = lshr i32 %a, 1 %add = and i32 %0, 2147483646...

...; > should a pattern only be applied if there is only one user? Is it > > valid if there are more that one users, if we cannot move something > > into the destination block can we still apply the pattern is we move > > the result in the source block, etc. > > The existing hasOneUse() checks can be done via by defining a GIMatchPredicate like so: > def hasOneUse : GIMatchPredicate<(ins reg:$A), bool, [{ > return MRI.hasOneUse(${A}); > }]>; > and then using it in the match section. Improving on hasOneUse() to support the cases where some/all use...

...optimizer. As long as we don't go "crazy" trying to recover the performance, it should be OK. Hal has already put together the patches needed for his current approach. We'll likely have to tweak this approach a little, but we don't need to go throguh and change every single hasOneUse() check to do something special with these invariants (or assumptions). > I can see a couple of possibilities here: > - Canonicalize the placement of "llvm.invariants: at the end of each basic > block. This at least reduces the patterns to be matched. > I think that the use o...

...VM, and we don't have a good general scheme for handling them. Currently, special handling for llvm.dbg, expect, etc. are coded into several (many) different places to make them appear free, and adding more in a similar way might become unmanageable. Even worse, these intrinsics break the "hasOneUser" check, and this interferes with optimization. This may not be important for debug intrinsics, but certainly is for features intended to help optimization. Based on this, it seems that we need to differentiate two classes of users: real users and, as Chandler called them, ephemeral users. W...

...VM, and we don't have a good general scheme for handling them. Currently, special handling for llvm.dbg, expect, etc. are coded into several (many) different places to make them appear free, and adding more in a similar way might become unmanageable. Even worse, these intrinsics break the "hasOneUser" check, and this interferes with optimization. This may not be important for debug intrinsics, but certainly is for features intended to help optimization. > > Based on this, it seems that we need to differentiate two classes of users: real users and, as Chandler called them, ephemera...

Hi, >> DAGCombiner::visitBRCOND() has code: >> >> SDValue N1 = N->getOperand(1); >> SDValue N2 = N->getOperand(2); >> >> ... >> >> SDNode *Trunc = 0; >> if (N1.getOpcode() == ISD::TRUNCATE&& N1.hasOneUse()) { >> // Look past truncate. >> Trunc = N1.getNode(); >> N1 = N1.getOperand(0); >> } >> >> which just drops the truncate away. this looks wrong. According to the documentation of BRCOND, // BRCOND - Conditional branch. The first oper...

...r8, r5 MUL r6, r8, r9 to MUL r6, -r5, r9 Is there a Pattern<> syntax that would allow matching *any* opcode (or even some subset), not just MUL, with a FNEG'd operand? I expect I can define a PatFrag: def fneg_su : PatFrag<(ops node:$val), (fneg node:$val), [{ return N->hasOneUse(); }]>; and then use that in each target instruction patten in XXXInstrInfo.td, such as: def XXX_MUL : XXXInst< (outs GPR32:$dst), (ins GPR32:$src1, GPR32:$src2), "mul $dst, -$src1, $src2", [(set $dst, (mul (fneg_su GPR32:$src1), GPR32:$src2))]>; but I would like...

...c1, GPR32:$src2), "!strcat(opc, " $dst, -$src1, $src2")", [(set $dst, (op (fneg_su GPR32:$src1), GPR32:$src2)))]>; } > I expect I can > define a PatFrag: > > def fneg_su : PatFrag<(ops node:$val), (fneg node:$val), [{ return > N->hasOneUse(); }]>; AFAIK, you don't need to verify for hasOneUse() because the instruction selector will do it for you. Also, it's too restrictive if fneg_su is used alone in some other matching rule. > and then use that in each target instruction patten in XXXInstrInfo.td, such as: > &g...

...sers. E.g., > should a pattern only be applied if there is only one user? Is it > valid if there are more that one users, if we cannot move something > into the destination block can we still apply the pattern is we move > the result in the source block, etc. > > > The existing hasOneUse() checks can be done via by defining a GIMatchPredicate like so: > def hasOneUse : GIMatchPredicate<(ins reg:$A), bool, [{ > return MRI.hasOneUse(${A}); > }]>; > and then using it in the match section. Improving on hasOneUse() to support the cases where some/all uses a...

> I really dislike hasOneUse-based "solutions" at the IR / InstCombine layer. > They result in strange artifacts during optimization: places where adding > similar code turns off optimizations because we fold the similar bits > together and reuse parts of the computation. > > I would much rather see u...

...onst)', the RHS is 0, // the test is for equality or unsigned, and all 1 bits of the const are // in the same partial word, see if we can shorten the load. if (DCI.isBeforeLegalize() && N0.getOpcode() == ISD::AND && C1 == 0 && N0.getNode()->hasOneUse() && isa<LoadSDNode>(N0.getOperand(0)) && N0.getOperand(0).getNode()->hasOneUse() && isa<ConstantSDNode>(N0.getOperand(1))) { LoadSDNode *Lod = cast<LoadSDNode>(N0.getOperand(0)); APInt bestMask; [...] This shouldn...

...scheme for handling them. Currently, special handling for > > llvm.dbg, expect, etc. are coded into several (many) different > > places to make them appear free, and adding more in a similar way > > might become unmanageable. Even worse, these intrinsics break the > > "hasOneUser" check, and this interferes with optimization. This > > may not be important for debug intrinsics, but certainly is for > > features intended to help optimization. > > > > Based on this, it seems that we need to differentiate two classes > > of users: real user...

Thanks. I have checked the hook DAGCombiner::isMulAddWithConstProfitable And I think the above condition is too aggressive. // If the add only has one use, this would be OK to do. if (AddNode.getNode()->hasOneUse()) return true; Shall we make it to if (AddNode.getNode()->hasOneUse() && TargetLowering.isCheaperCommuteAddMul(......)) return true; The virtual hook nethod isCheaperCommuteAddMul will return true by default, but specific targets like arm/riscv can make their own decisio...

...lowest bit. This routine then goes to SelectionDAG:Combine() which runs DAGCombiner::visitBRCOND(). DAGCombiner::visitBRCOND() has code: SDValue N1 = N->getOperand(1); SDValue N2 = N->getOperand(2); ... SDNode *Trunc = 0; if (N1.getOpcode() == ISD::TRUNCATE && N1.hasOneUse()) { // Look past truncate. Trunc = N1.getNode(); N1 = N1.getOperand(0); } which just drops the truncate away.. then there is another optimization afterwards.. // Transform br(xor(x, y)) -> br(x != y) // Transform br(xor(xor(x,y), 1)) -> br (x == y) if (N1.hasOne...

...a good general > scheme for handling them. Currently, special handling for > llvm.dbg, expect, etc. are coded into several (many) different > places to make them appear free, and adding more in a similar way > might become unmanageable. Even worse, these intrinsics break the > "hasOneUser" check, and this interferes with optimization. This > may not be important for debug intrinsics, but certainly is for > features intended to help optimization. > > Based on this, it seems that we need to differentiate two classes > of users: real users and, as Chandler called...