similar to: [LLVMdev] Error running spec benchmark with FMA4 on X86

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

Hi, I have a simple question w.r.t the order of operands used in dag pattern matching in target files. Some of them seem intuitive. But I want to get it clarified anyway. I am using a pattern from X86InstrFMA.td in the below example. Consider FMA3 pattern (simplified). let Constraints = "$src1 = $dst" in { multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand

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,

On 16 November 2012 13:41, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > Hi, > > I have a simple question w.r.t the order of operands used in dag > pattern matching in target files. Some of them seem intuitive. But I > want to get it clarified anyway. I am using a pattern from > X86InstrFMA.td in the below example. Consider FMA3 pattern > (simplified). >

Hi Anitha, > http://llvm.org/bugs/show_bug.____cgi?id=14185 > <http://llvm.org/bugs/show_bug.__cgi?id=14185> > > <http://llvm.org/bugs/show___bug.cgi?id=14185 > <http://llvm.org/bugs/show_bug.cgi?id=14185>> > I am stuck on analysis. Does any one have alternate suggestions > on debugging >

On 6 November 2012 14:53, Duncan Sands <baldrick at free.fr> wrote: > Hi Anitha, > > > On 05/11/12 10:29, Anitha Boyapati wrote: > >> >> >> On 5 November 2012 14:32, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> Hi Anitha, >> >> >>

The buildbots are unhappy again. :-( Specifically, the "llvm-gcc-i386-darwin9" buildbot here at Apple last compiled TOT successfully yesterday morning (31aug); that was revision 80586. By revision 80589, the bootstrap failed due to a miscompare, and by revision 80610, it's aborting while compiling little pieces of libgcc. 80586 built O.K. (about 8AM, Pacific Standard

Yes, this is pretty unacceptable IMHO. I would go revert crazy if I knew what to hit, unfortunately I don't. Currently I believe there are two problems, a CallGraphSCC assert which is firing everywhere (including the clang test suite, *cough*). This started with 80698. Chris is working on this (if it isn't already fixed). The bootstrap comparison failures are being looked at by Devang.

Hi, I am looking for the compiler flags/technique for the following code generations in llvm 1) enable and disable FMA3 and FMA4 instruction generation. 2) Enable and disable the vectorized FMA3 and FMA4 instruction generation. Please suggest. Thanks in advance. Best Regards, soham "The search for truth is more precious than its possession." -------------- next part

You've unfortunately chosen a complex example. Your second question is needs be answered first. null_frag causes the pattern to be dropped. Now having covered that the reason the operands are in the order they are is because the only instruction that doesn't use null_frag is this one defm r213 : fma3s_rm<opc213, !strconcat(OpStr, !strconcat("213", PackTy)),

Dear LLVM contributors, I am Naoki Shibata, an associate professor at Nara Institute of Science and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library,

On 03/30/2010 09:21 PM, Török Edwin wrote: > On 03/30/2010 09:15 PM, Tanya Lattner wrote: >> Thanks for testing the release! >> >>> Tests were run on x86-64, Debian unstable, Linux 2.6.33, gcc 4.4.3, >>> 64-bit. I built srcdir == objdir, I have built llvm and clang myself, >>> and used the binaries for llvm-gcc. >>> >>> 1. llvm-gcc 2.7 vs

On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > I'm still slightly confused. Is the error now fixed or is there still a bug > in LLVM's integrated assembler? > The error is not fixed yet (even with fix mentioned in PR15040 http://llvm.org/bugs/show_bug.cgi?id=15040#c4) With the updated trunk, clang still gives an error when FMA4 is enabled but

Can you send the binaries compiled with and without the integrated assembler. Maybe I can figure out the encoding problem. I've been unsuccessful figuring it out myself so far. On Tue, Mar 12, 2013 at 12:34 AM, Anitha B Gollamudi < anitha.boyapati at gmail.com> wrote: > On 12 March 2013 09:51, Craig Topper <craig.topper at gmail.com> wrote: > > I'm still slightly

On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >> >> Are you still having issues with FMA4? I wonder if PR15040 is related. A >> fix was just committed. Unfortunately r173176 does not fix this. I have updated the trunk and ran...Miscompare still persists.

This is a bit premature to be considered a code review, but given how unfamiliar I am with SelectionDAG (& that I'm seeing somewhat more 'interesting' results compared to my change to FastISel) I wanted to get a bit of feedback to see if I was on the right track or had missed any obvious cases. I've attached my patch in progress (including a modification to the existing test

On 11 March 2013 16:13, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: > On 11 March 2013 10:06, Anitha B Gollamudi <anitha.boyapati at gmail.com> wrote: >> On 23 January 2013 00:20, Craig Topper <craig.topper at gmail.com> wrote: >>> >>> Are you still having issues with FMA4? I wonder if PR15040 is related. A >>> fix was just

On Thursday 25 February 2010 15:33:58 Jan Sjodin wrote: > I have seen some re-factoring work done to prepare for AVX support. What > are the plans (time wise) to add the AVX patterns to the backend? Has > anyone thought about FMA4? Oh yes. :) FMA4 will have a different feature bit than AVX or FMA3. FMA4 is our top priority after AVX due to Bulldozer. What would you like to see for