search for: hasoneuser

> 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

It appears impossible to match memory-to-memory instructions (except for MOV). The MSP430 supports these. The following test case tries to match the pattern that generates "add.w &foo,&bar": ; RUN: llvm-as < %s | llc -march=msp430 -O3 target datalayout = "e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8" target triple = "msp430-generic-generic" @foo = common global

On Tue, Apr 17, 2012 at 1:36 PM, Rafael Espíndola < 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.

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

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

Look at this silly function: $ cat small.c unsigned f(unsigned a, unsigned *p) { unsigned x = a/4; p[0] = x; p[1] = x+x; return p[1] - 2*p[0]; } GCC turns this into straightforward code and figures out the 0 return value: shrl $2, %edi movl %edi, (%rsi) addl %edi, %edi movl %edi, 4(%rsi) movl $0, %eax ret LLVM optimizes the code: $ clang -O -S -o- small.c -emit-llvm define i32

Hi Daniel, Thanks for the reply! Le lun. 26 nov. 2018 à 10:00, Daniel Sanders <daniel_l_sanders at apple.com> a écrit : > > Hi Quentin, > > Sorry for the slow reply. > > > On Nov 16, 2018, at 09:25, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > > > Hi Daniel, > > > > I finally read the proposal. > > > > I have a

On Thu, Jul 17, 2014 at 5:31 PM, Philip Reames <listmail at philipreames.com> wrote: > 3. An "llvm.invariant" has zero code generation cost. Given that, a lot > of pattern matching and profitability heuristics will need adjusted to > ignore them. > FWIW, this has been the fundamental point of contention in the entire design. I've discussed this several times with

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

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

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);

I've been unable to come up with the TableGen recipe to match a negated operand. My target asm syntax allows the following transform: FNEG 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

Hi Joe, Le 11/05/2012 02:13, Joe Matarazzo a écrit : > I've been unable to come up with the TableGen recipe to match a > negated operand. My target asm syntax allows the following transform: > > FNEG 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

Hi Daniel, Let me try to clarify my concern. Le mar. 27 nov. 2018 à 14:23, Daniel Sanders <daniel_l_sanders at apple.com> a écrit : > > > > On Nov 26, 2018, at 10:11, Quentin Colombet <quentin.colombet at gmail.com> wrote: > > Hi Daniel, > > Thanks for the reply! > > Le lun. 26 nov. 2018 à 10:00, Daniel Sanders > <daniel_l_sanders at apple.com>

> 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 us devise a reasonable set of canonicalization rules > at the IR

On Wed, Jul 27, 2011 at 3:50 PM, Matt Johnson <johnso87 at crhc.illinois.edu> wrote: > Hi Eli, > > On 07/27/2011 04:59 PM, Eli Friedman wrote: >> >> On Wed, Jul 27, 2011 at 2:28 PM, Matt Johnson >> <johnso87 at crhc.illinois.edu>  wrote: >>> >>> Hi All, >>>     I'm writing a backend for a target which only supports 4-byte,

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

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

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set

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