search for: commutative

Hi all, The 213 variant of the FMA3 instructions is currently marked commutable (see X86InstrFMA.td). Is that safe? According to the ISA the FMA3 instructions aren't commutable for non-numeric results, so I'd have thought commuting this would only be valid in fast-math mode? For the curious, the reason that I'm asking is that we currently always select the 213 variant, but this

Hi Kay, My patch will partially address your bug. For now I'm just looking to switch the default FMA from vfmadd213xx to vfmadd231xx. That will cause the code in PR17229 to compile as desired, but would regress code like: double foo(double a, double b, double c) { return a * b + c; } Which will now require a vmovaps + vfmadd231. If this impacts real benchmarks we could add an

Hi Lang, Unfortunately, I don't have an answer on the commutability question, but I wanted to let you know that I filed a bug on this: http://llvm.org/bugs/show_bug.cgi?id=17229 This also shows a memory operand variant of the fma that you may want to consider in your patch and testcases. Thanks! On Thu, Dec 19, 2013 at 10:45 PM, Lang Hames <lhames at gmail.com> wrote: > Hi all,

...231 variant. Cheers, Lang. On Sat, Dec 21, 2013 at 11:42 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > 1) Our architects say that vmovaps %reg, %reg causes only register renaming in HW and does not affect performance. > > 2) The non-numeric result of FMA is not commutative for multiplicand and the multiplier. You are right. This property should be removed. > > > - Elena > > -----Original Message----- > From: Lang Hames [mailto:lhames at gmail.com] > Sent: Friday, December 20, 2013 23:03 > To: Kay Tiong Khoo > Cc: LLVM Developers Mailing Li...

Hey All, very simple question for you folks ;) I have a @commutes object that for each record there is a bit value set (0/1) to denote if an accident occurred. What I want to do is have it display "Yes" or "No" when I view the listing of commutes. I can get it to display the bit value just fine with <%= commute.accident %> but how can I get it so that when a record with

Dan Gohman wrote: > On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: > >> Because sextb_r and sextw_r have destination tied to source operands, >> TwoAddressInstructionPass thinks it needs a copy. However, since the >> sext kills its source, the copy is unnecessary. Why does this happen? >> Is TwoAddressInstructionPass relying on a later pass to notice this

I noticed that the operand commuting code in X86InstrInfo.cpp treats scalar FMA intrinsics specially. It prevents operand commuting on these scalar instructions because the scalar FMA instructions preserve the upper bits of the vector. Presumably, the restrictions are there because commuting operands potentially changes the result upper bits. However, AFAIK the Intel and GNU FMA intrinsics

...em. SelectionDAG has 9 nodes: t0: ch = EntryToken t4: i16,ch = CopyFromReg t0, Register:i16 %1 t2: i16,ch = CopyFromReg t0, Register:i16 %0 t5: i16 = mul t4, t2 t7: ch,glue = CopyToReg t0, Register:i16 $r0, t5 t8: ch = CPU74ISD::RET_FLAG t7, Register:i16 $r0, t7:1 Given the commutative nature of multiplication, the arguments could be passed in the same order they are received (a,b) so that they would not need to be swapped before the __mulhi3 call What am I missing?, Thanks, John Lluch. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

On Jun 25, 2009, at 6:06 PM, Evan Cheng wrote: > > On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > >> Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) >> have similar patterns, as we would expect: >> >> defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not >> node:$RHS))>>; >> defm t2ORN :

On Jun 25, 2009, at 4:38 PM, David Goodwin wrote: > Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) > have similar patterns, as we would expect: > > defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: > $RHS))>>; > defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node: >

Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) have similar patterns, as we would expect: defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: $RHS))>>; defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node: $RHS))>>; Compiling the following three works as expected: %tmp1 = xor i32

...parisons should be able to commute their operands. But, for ARM at least, this does not seem to be happening. The first sequence below generates CMN (compare negated) but the second does not (complete test attached). These seem to map to ARMcmpNZ. Where would I look to see if that is marked commutative? %nb = sub i32 0, %b %tmp = icmp ne i32 %a, %nb %nb = sub i32 0, %b %tmp = icmp ne i32 %nb, %a David -------------- next part -------------- A non-text attachment was scrubbed... Name: thumb2-cmn.ll Type: application/octet-stream Size: 526 bytes Desc: not available URL: <...

...i Stephen, > > > On 14/01/2012 21:26, Stephen McGruer wrote: > >> Dear all, >> >> I was wondering if it is possible in TableGen to either: >> >> 1. Selectively define an instruction depending on an SDNode's >> properties, e.g. if the SDNode is not commutative. >> 2. Override/ignore the TableGen error given when a commutative node has >> an immediate on the LHS. >> >> My case comes from trying to define a generic ALU operation multiclass >> for my target, which includes a "dest_reg,immediate,src_reg" format. >&g...

...rn matching in InstructionCombine pass. We use 'match' functions many times, but it doesn't do the pattern matching effectively. e.x. Lets take pattern : (A ^ B) | ((B ^ C) ^ A) -> (A ^ B) | C (B ^ A) | ((B ^ C) ^ A) -> (A ^ B) | C Both the patterns above are same, since ^ is commutative in Op0. But, 'match' pattern has to be written for both the patterns separately since 'match' identifies pattern as it (like regular expression) and doesn't have the logic to determine that 'A^B' and 'B^A' are same. I propose to improve 'match' function...

Dear all, I was wondering if it is possible in TableGen to either: 1. Selectively define an instruction depending on an SDNode's properties, e.g. if the SDNode is not commutative. 2. Override/ignore the TableGen error given when a commutative node has an immediate on the LHS. My case comes from trying to define a generic ALU operation multiclass for my target, which includes a "dest_reg,immediate,src_reg" format. This is disallowed for commutative SDAG nodes (e.g...

Hi, What does it mean when "Commutative" property is applied to an intrinsic with more than two arguments? For example, __builtin_ia32_dppd has this property. Thanks. -- Simon

...oats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >> > > Are you marking add as commutable? Are you making mov as a copy > instruction? > How do I mark them? For the commutative property, I observed this definition: def add : SDNode<"ISD::ADD" , SDTIntBinOp , [SDNPCommutative, SDNPAssociative]>; ... and assumed it was sufficient, since I saw no other targets making special arrangements. I see no obvious (to me, an...

On Apr 21, 2009, at 4:02 PM, Greg McGary wrote: > Dan Gohman wrote: >> On Apr 19, 2009, at 6:15 PM, Greg McGary wrote: >> >>> Because sextb_r and sextw_r have destination tied to source >>> operands, >>> TwoAddressInstructionPass thinks it needs a copy. However, since >>> the >>> sext kills its source, the copy is unnecessary. Why

...s.. x != 5 OR x == 8 becomes.. x != 5 However, a different ordering prevents the simplification: x == 8 OR x > 10 OR x != 5 becomes.. %or.eq8.gt10 OR x != 5 and that can't be simplified because we now have an "or" OR "icmp". What would I need to implement to restore the commutative property? Perhaps a first stab would be to take (A|B)|C create two binaryOp A|C and B|C and recursively call visitOr on each of them to see if they simplify. Using the example above.. Before: %or.eq8.gt10 = .. ; [uses=1] %res = or %or.eq8.gt10, %ne5 ; original instruction After: %or.eq8.gt10 = ....

...!= 5 > > However, a different ordering prevents the simplification: > x == 8 OR x > 10 OR x != 5 becomes.. > %or.eq8.gt10 OR x != 5 > and that can't be simplified because we now have an "or" OR "icmp". > > What would I need to implement to restore the commutative property? > > Perhaps a first stab would be to take (A|B)|C create two binaryOp A|C > and B|C and recursively call visitOr on each of them to see if they > simplify. Using the example above.. > > Before: > %or.eq8.gt10 = .. ; [uses=1] > %res = or %or.eq8.gt10, %ne5 ; origina...