search for: tiong

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

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

...If the comparison were unsigned or the shl had a nsw flag, I think this would be okay. Since none of these is true, I don't think this transformation is correct. H. On Sat, Nov 16, 2013 at 1:41 AM, Mark Lacey <mark.lacey at apple.com> wrote: > > On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: > > I've been diagnosing this bug: > http://llvm.org/bugs/show_bug.cgi?id=17827 > > Summary: I think the following program miscompiles at -O1 because the fact > that 'f0' is a signed 3-bit value is lost in the unoptimized LLV...

On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: > I've been diagnosing this bug: > http://llvm.org/bugs/show_bug.cgi?id=17827 > > Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. Ho...

Just to clarify: gcc 4.8.1 generates that fma at -O2; no FP relaxation or other flags specified. On Wed, Dec 18, 2013 at 6:02 PM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Thanks for the explanation, Tim! > > gcc 4.8.1 *does* generate an fma for your code example for an x86 target > that supports fma. I'd bet that the HW vendors' compilers do the same, but > I don't have any of those installed a...

I've been diagnosing this bug: http://llvm.org/bugs/show_bug.cgi?id=17827 Summary: I think the following program miscompiles at -O1 because the fact that 'f0' is a signed 3-bit value is lost in the unoptimized LLVM IR. How do we fix this? $ cat bitfield.c /* %struct.S = type { i8, [3 x i8] } ??? */ struct S { int f0:3; } a; int foo (int p) { struct S c = a; c.f0 = p & 6;

...EON) instruction? Can someone please clarify on this point? The performance gain with vmla instruction is huge. Somewhere i read that LLVM prefers precision accuracy over performance. Is this true and hence LLVM is not emiting vmla instructions for cortex-a8? On Thu, Dec 19, 2013 at 6:41 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Just to clarify: gcc 4.8.1 generates that fma at -O2; no FP relaxation or > other flags specified. > > > On Wed, Dec 18, 2013 at 6:02 PM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > >> Thanks for the explanation, Tim!...

Thanks for the explanation, Tim! gcc 4.8.1 *does* generate an fma for your code example for an x86 target that supports fma. I'd bet that the HW vendors' compilers do the same, but I don't have any of those installed at the moment to test that theory. So this is a bug in those compilers? Do you know how they justify it? I see section 6.5 "Expressions" in the C standard, and

...nsw flag, I > think this would be okay. Since none of these is true, I don't think this > transformation is correct. > > H. > > > > On Sat, Nov 16, 2013 at 1:41 AM, Mark Lacey <mark.lacey at apple.com> wrote: > >> >> On Nov 15, 2013, at 3:42 PM, Kay Tiong Khoo <kkhoo at perfwizard.com> wrote: >> >> I've been diagnosing this bug: >> http://llvm.org/bugs/show_bug.cgi?id=17827 >> >> Summary: I think the following program miscompiles at -O1 because the >> fact that 'f0' is a signed 3-bit value is los...

On Thu, Nov 28, 2013 at 1:03 AM, Kay Tiong Khoo <kkhoo at perfwizard.com>wrote: > Hi Jun, > > I'm not sure how to fix this yet, but this looks incorrectly defined in > lib/Target/X86/X86InstrInfo.td: > > def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), > "mov{l}\t...

...nnot be applied to a pointer to an incomplete struct or union. make: The error code from the last command is 1. Stop. make: The error code from the last command is 2. Stop. make: The error code from the last command is 1. Stop. make: The error code from the last command is 1. Stop. thanks Tiong

...RC (2007-04-22 r41276) ----- Original Message ----- From: "Prof Brian Ripley" <ripley at stats.ox.ac.uk> To: <R-devel at r-project.org> Cc: "Sheth, Jagat K" <jagat.k.sheth at citigroup.com>; "kamil Marcinkowski" <kamil at ualberta.ca>; "Tiong Lim" <t.lim at auckland.ac.nz>; "Eric Harley" <ericctharley at gmail.com>; "Matthew Beason" <mbeason at harrahs.com>; <watplatt at us.ibm.com> Sent: Wednesday, March 28, 2007 11:27 PM Subject: [Rd] AIX testers needed > With much thanks to Ei-ji...

Hi Jun, I'm not sure how to fix this yet, but this looks incorrectly defined in lib/Target/X86/X86InstrInfo.td: def MOV32o32a : Ii32 <0xA1, RawFrm, (outs), (ins offset32:$src), "mov{l}\t{$src, %eax|eax, $src}", [], IIC_MOV_MEM>, Requires<[In32BitMode]>; This instruction can be REX-prefixed for a 64-bit move, and that also

Hi, With objdump, i have this (Intel syntax) 64 a1 00 00 00 00 mov eax,fs:0x0 However, if I pass above string to llvm-mc, I would have: $ echo "0x64 0xa1 0x00 0x00 0x00 0x00"|./Release+Asserts/bin/llvm-mc -disassemble -arch=x86 --output-asm-variant=1 .text mov eax, dword ptr [0] You can see a big difference. This is on the latest code. Any idea how to

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,

With much thanks to Ei-ji Nakama, R 2.5.0 alpha supports building on AIX (at least AIX 5.2 on one system). Would anyone able to test this please get the latest tarball from http://cran.r-project.org/src/base-prerelease/R-latest.tar.gz and try installing (after reading the AIX notes in R-admin.html section C.9). In particular it would be very helpful to know if 1) --enable-BLAS-shlib works

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

On Dec 15, 2013, at 7:10 PM, C. Bergström <cbergstrom at pathscale.com> wrote: > On 12/16/13 09:57 AM, Bill Wendling wrote: >> On Dec 12, 2013, at 11:08 PM, C. Bergström <cbergstrom at pathscale.com> wrote: >> >>> On 12/13/13 01:58 PM, Bill Wendling wrote: >>>> That’s a long laundry list of bugs there. It would be great to have them fixed, but the

Recently, I've seen a few bugs filed against llvm "trunk" because "3.3" isn't in the list of versions in LLVM bugzilla. This is causing confusion for customers and wasting time for devs. "3.3" does exist for the clang product, but nowhere else it seems. Can someone with bugzilla admin power add "3.3" as a version for other products and the

Thanks, Tim! As Craig noted: http://llvm.org/bugs/show_bug.cgi?id=16962#c1 "There are many things wrong with these instructions." :) On Wed, Nov 27, 2013 at 10:17 AM, Tim Northover <t.p.northover at gmail.com>wrote: > > I would file a bugzilla in the x86 component and cc Craig Topper, the x86 > > disasm/codegen expert. > > If you chase down the revision