search for: fma3

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

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

...gt; 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, >> >> 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 th...

...> > > - 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 List; Demikhovsky, Elena; Craig Topper > Subject: Re: [LLVMdev] Commutability of X86 FMA3 instructions. > > 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...

Hi All, I am facing miscompare error when running povray (and few other C/C++ benchmarks) from spec cpu2006 suite enabling FMA4 (and disabling FMA3). I have used -ffp-contract=fast to turn on this option. (Compilation options and targets pasted below). >>>>>>>> clang version 3.2 (trunk 163295:163308) (llvm/trunk 163295) Target: x86_64-unknown-linux-gnu Thread model: posix (Options to clang) -O3 -march=bdver2 -mavx...

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 x86memop, RegisterClass RC, ValueType OpVT, PatFrag mem_frag, SDPatternOperator OpNode = null_frag> { def r...

...ti 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). > > let Constraints = "$src1 = $dst" in { > multiclass fma3s_rm<bits<8> opc, string OpcodeStr, X86MemOperand x86memop, > RegisterClass RC, ValueType OpVT, PatFrag mem_frag, > SDPatternOperator OpNod...

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 -------------- An HTML attachment...

...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)), x86memop, RC, OpVT, mem_frag, OpNode> Which specifies the operand order as 213 thus why they are 2, 1, 3 in the pattern. ~Craig On Fri, Nov 16, 2012 at 12:19 AM, Anitha B Gollamudi < anitha.boyapati...

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

...o developed a user-facing header for the library, in the style of Clang's intrinsics headers, which we can use as part of this project. SLEEF has been used as part of bgclang in this way for several years. The library currently supports several architectures: * x86 - SSE2, FMA4, AVX, AVX2+FMA3 * ARM - NEON (single-precision only) * A pure C (scalar) version * Hal's version supports PowerPC/QPX. It is faily easy to port to other architectures. The library provides similar functionality to Intel's Short Vector Math Library (available with Intel's Compiler). Roadmap: -...

On Wednesday 24 February 2010 18:47:19 Dan Gohman wrote: > SDUse's Prev and Next members implement a use list. Copying them > probably wouldn't immediately break anything, but it wouldn't be > meaningful. I understand that the copied SDUse wouldn't be represented in the list, so I can understand the general reasons for making the copy constructor private. In this case,

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

...rsday 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 FMA4? I will be implementing that just as soon as I push up some more AVX support. The AVX work is ready to be pushed up and I am working on that. Unfortunately, pesky things like software releases are getti...

...deGen/X86/win64_params.ll:7:10: error: expected string not found in input ; CHECK: movl 48(%rsp), %eax ^ <stdin>:1:2: note: scanning from here .def f6; ^ <stdin>:9:2: note: possible intended match here movl 40(%rsp), %eax ^ -- ******************** FAIL: LLVM :: CodeGen/X86/fma3-intrinsics.ll (44 of 51) ******************** TEST 'LLVM :: CodeGen/X86/fma3-intrinsics.ll' FAILED ******************** Script: -- /usr/local/google/home/blaikie/dev/llvm/build/clang/debug/bin/./llc < /usr/local/google/home/blaikie/dev/llvm/src/test/CodeGen/X86/fma3-intrinsics.ll -mtripl...

> On Sep 16, 2015, at 9:45 AM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 16, 2015 at 7:47 AM, Teresa Johnson <tejohnson at google.com> wrote: >> On Tue, Sep 15, 2015 at 3:31 PM, Duncan P. N. Exon Smith via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>>> On 2015-Sep-02, at 19:31, Peter