search for: commut

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

...+ vfmadd231. If this impacts real benchmarks we could add an optimization to change the FMA variant based on how it's used. - Lang. On Fri, Dec 20, 2013 at 8:29 AM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: > 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 1...

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

Hi Elena, Thank you very much for looking in to that. I'll go ahead and remove the isCommutable flag from those instructions, since it sounds like that's the right thing to do. I would still like to change the default from the 231 variant to 213 too, as this will reduce code-size for accumulator-style loops. I have at least one benchmark that shows significant speedups when this chang...

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

...otice this >> and >> transform it again? >> > > Yes, the later pass is the coalescer. It would be worthwhile to > understand why it is not coalescing the copies. > I discovered a curious phenomenon: The copies are necessary because TwoAddressInstructionPass commutes the second add. When I suppress the commute, the movs disappear and the code became optimal. It seems the two-address commuter is either buggy or inherently short-sighted/simple-minded and paints itself into a corner. How do you recommend I approach this problem? G

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

A few library calls are commutable by definition, for example multiplications. I defined them as LibCalls for my architecture. However, I found that arguments are always passed in the order they are generated by Clang thus missing possible optimisations. For example, the following IR code ; Function Attrs: minsize norecurse n...

...%a, %tmp -- >> > bic r0, r0, r1 >> >> But this doesn't: >> >> %tmp = xor i32 %b, 4294967295 ; %tmp1 = and i32 %tmp, %a -- >> > eor r1, r1, #4294967295 ; and r0, r1, r0 >> >> On the surface it seems that the selector is not commuting the AND >> operands. I've attached the complete test files. I can take a look >> but I need a pointer to get started. > > No, isel is trying to commute the AND. See ARMGenDAGISel.inc (auto- > generated by tablegen): > > // Pattern: (and:i32 GPR:i32:$lhs, (...

...4294967295 ; %tmp1 = and i32 %a, %tmp -- > > bic r0, r0, r1 > > But this doesn't: > > %tmp = xor i32 %b, 4294967295 ; %tmp1 = and i32 %tmp, %a -- > > eor r1, r1, #4294967295 ; and r0, r1, r0 > > On the surface it seems that the selector is not commuting the AND > operands. I've attached the complete test files. I can take a look > but I need a pointer to get started. No, isel is trying to commute the AND. See ARMGenDAGISel.inc (auto- generated by tablegen): // Pattern: (and:i32 GPR:i32:$lhs, (xor:i32 t2_so_reg:i32:$rhs,...

...r0, r0, r1 %tmp = xor i32 %b, 4294967295 ; %tmp1 = and i32 %a, %tmp -- > bic r0, r0, r1 But this doesn't: %tmp = xor i32 %b, 4294967295 ; %tmp1 = and i32 %tmp, %a -- > eor r1, r1, #4294967295 ; and r0, r1, r0 On the surface it seems that the selector is not commuting the AND operands. I've attached the complete test files. I can take a look but I need a pointer to get started. David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090625/0706b1cb/attachment...

NE and EQ comparisons 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...

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

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

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

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

...operly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> 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...

...> transform it again? >>> >> >> Yes, the later pass is the coalescer. It would be worthwhile to >> understand why it is not coalescing the copies. >> > > I discovered a curious phenomenon: > > The copies are necessary because TwoAddressInstructionPass commutes > the second add. When I suppress the commute, the movs disappear and > the code became optimal. It seems the two-address commuter is > either buggy > or inherently short-sighted/simple-minded and paints itself into a > corner. > > How do you recommend I approach this p...

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

...!= 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 ; or...