search for: robison

Thanks! That’s probably close enough for practical purposes. I looked at the overrides on various targets, and they all return true if the FMA hardware exists. - Arch From: Jingyue Wu [mailto:jingyue at google.com] Sent: Wednesday, December 10, 2014 2:56 PM To: Robison, Arch Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Best way for JIT to query whether llvm.fma.* is fast? Does TargetLowering::isFMAFasterThanFMulAndFAdd (http://llvm.org/docs/doxygen/html/TargetLowering_8h_source.html#l01499) help? Jingyue On Wed, Dec 10, 2014 at 12:48 PM, Robison, Arch &lt...

...e comparisons (which are themselves partially ordered) a bit tricky... Philip (Who knows just enough about floating point to know he doesn't really know what's he's talking about.) On 01/08/2015 11:45 AM, Hal Finkel wrote: > ----- Original Message ----- >> From: "Arch Robison" <arch.robison at intel.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Philip Reames" <listmail at philipreames.com>, llvmdev at cs.uiuc.edu >> Sent: Thursday, January 8, 2015 1:26:41 PM >> Subject: RE: [LLVMdev] Floating-poi...

...de issues and considerably more work for smaller gain. I like the idea of creating an FPRange class. We could start with a simple one and extend it as experience warrants. - Arch -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, January 8, 2015 1:03 PM To: Robison, Arch Cc: Philip Reames; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Floating-point range checks ----- Original Message ----- > From: "Arch Robison" <arch.robison at intel.com> > To: "Philip Reames" <listmail at philipreames.com>, llvmdev at cs.uiuc.edu >...

...of the cases of practical interest are eliminating domain checks and optimizations that need to know that Nan/Inf are not in play. - Arch -----Original Message----- From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Thursday, January 8, 2015 3:24 PM To: Philip Reames Cc: llvmdev at cs.uiuc.edu; Robison, Arch Subject: Re: [LLVMdev] Floating-point range checks ----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Arch Robison" > <arch.robison at intel.com> > Cc: llvm...

...ints for floating-point could be all subsets of the eight-element set: {-inf,<0,-0,+0,>0,+inf,-nan,+nan}, where <0 and >0 denote finite negative/positive numbers respectively. - Arch From: Philip Reames [mailto:listmail at philipreames.com] Sent: Wednesday, January 7, 2015 6:03 PM To: Robison, Arch; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Floating-point range checks I don't believe we have much in this area currently. Generally, something like this would existing in InstCombine and ValueTracking. Take a look at ComputeSignBit in ValueTracking.cpp. This doesn't apply (?...

...ke be able to tell whether the llvm.fma.* intrinsic has hardware support. What's the best way to query LLVM (JIT) for this information? The information would be used in situations where the user wants to use different algorithms depending on whether FMA hardware is present or not. - Arch D. Robison -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/60216d28/attachment.html>

...mport_directory_begin(); import_directory_iterator E = Obj->import_directory_end(); if (I == E) return; outs() << "The Import Tables:\n"; for (; I != E; I = ++I) { ... } Is there a reason for writing "I = ++I" instead of "++I" ? - Arch D. Robison

...tself, LLVM will require infrastructure work to know when a lexically backwards dependence may have been introduced. Jon -----Original Message----- From: Tian, Xinmin [mailto:xinmin.tian at intel.com] Sent: Monday, September 29, 2014 10:43 AM To: Renato Golin; Hal Finkel Cc: Humphreys, Jonathan; Robison, Arch; LLVM Dev Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" Renato, I think Hal meant to ensure partial ordering, e.g. not to convert lexical forward data dep to lexical backward data dep due to statement ordering if any. ' Xinmin -----Original Message--...

...s: ; CHECK-LABEL: @i32_cast_cmp_oeq_int_n0_uitofp( ; CHECK: uitofp ; CHECK: fcmp oeq define i1 @i32_cast_cmp_oeq_int_n0_uitofp(i32 %i) { %f = uitofp i32 %i to float %cmp = fcmp oeq float %f, -0.0 ret i1 %cmp } Is this test really justified, or is it just reinforcing an oversight? - Arch D. Robison -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/d575d72e/attachment.html>

...ndency within the specified safe vector length VL. We will make this clear in the OpenMP 4.1 spec. Xinmin Tian (Intel) -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel Sent: Sunday, September 28, 2014 12:59 AM To: Robison, Arch Cc: Jonathan Humphreys; LLVM Dev Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" ----- Original Message ----- > From: "Arch Robison" <arch.robison at intel.com<mailto:arch.robison at intel.com>> > To: "Jonathan Humphreys&q...

...stead of just sending to the mailing list?) In article <CACs=tyJ6zaHeiS0eNhBkdcZE--JY4k7yH9_P1yFbGqod6uymMw at mail.gmail.com>, Reid Kleckner <rnk at google.com> writes: > Looks like a bug. This can probably be simplified with C++11. > > On Fri, Apr 4, 2014 at 10:39 AM, Robison, Arch <arch.robison at intel.com>wrote: > > > for (; I != E; I = ++I) { > > ... > > } > > > > Is there a reason for writing "I = ++I" instead of "++I" ? I don't see how it's a bug because functionality isn't impacted...

...es exist, but as you say, it's not obvious from the spec. One of our OpenMP community members is going to bring up the ambiguity with the OpenMP committee. - Arch -----Original Message----- From: Humphreys, Jonathan [mailto:j-humphreys at ti.com] Sent: Thursday, August 28, 2014 11:53 AM To: Robison, Arch; Hal Finkel; Renato Golin; Alexander Musman (alexander.musman at gmail.com) Cc: LLVM Dev Subject: RE: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" Well, having not understood the connection between lexical dependence and the openMP simd construct yesterday, I inquired...

...metadata !{metadata !"llvm.loop.vectorize.width", i32 4} !6 and !9 are in the list for loopID !8 and they specify conflicting widths. Is this a bug, or is there a deliberate convention that if there are multiple llvm.loop.vectorize.width annotations, only the last one counts? - Arch D. Robison Intel Corporation

...l evils, because the semantics turn out to be a little more subtle than just a minimum dependence distance. My current wording of the semantics for safelen of k are: /// The loop can be assumed to have no loop-carried /// lexically backward dependencies with distance less than k. - Arch D. Robison Intel Corporation

...particular, the transformation would seem to require casts of structures to vectors and back. The bitcast instruction requires a non-aggregate value. I'm thinking such vectorization might be useful for codes that use structs for tuples, like (x,y,z) coordinates or complex numbers. - Arch D. Robison -------------- next part -------------- A non-text attachment was scrubbed... Name: vec4.ll Type: application/octet-stream Size: 837 bytes Desc: vec4.ll URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140417/b5da8e36/attachment.obj>

...(Entry provided) (Zhen Li) 3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) 9. Re: Addressing const reference in ArrayRef (David Blaikie) 10. Re: Proposal for ""llvm.mem.vectorize.safelen" (Ar...

----- Original Message ----- > From: "Arnold Schwaighofer" <aschwaighofer at apple.com> > To: "Johannes Doerfert" <doerfert at cs.uni-saarland.de> > Cc: llvmdev at cs.uiuc.edu, "Arch Robison" <arch.robison at intel.com> > Sent: Wednesday, August 20, 2014 11:29:16 AM > Subject: Re: [LLVMdev] Proposal for ""llvm.mem.vectorize.safelen" > > > > On Aug 20, 2014, at 9:18 AM, Johannes Doerfert > > <doerfert at cs.uni-saarland.de> wrote...

...onditional branch taken if x<0. Alas this prevents vectorization of loops with sqrt. Often the argument can be proven to be non-negative. E.g., sqrt(x*x+y*y). Is there an existing LLVM pass or analysis that does floating-point range propagation to eliminate such unnecessary checks? Arch D. Robison Intel Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150107/89b401ea/attachment.html>

...hen Li) > 3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) > 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > 9. Re: Addressing const reference in ArrayRef (David Blaikie) > 10. Re: Proposal for ""llvm.mem.vectorize.saf...

...3. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 4. Re: Functions with unnamed parameters in LLVM IR (Tim Northover) > > 5. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 6. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > 7. Re: Functions with unnamed parameters in LLVM IR (Dan Liew) > > 8. Re: Proposal for ""llvm.mem.vectorize.safelen" (Robison, Arch) > > 9. Re: Addressing const reference in ArrayRef (David Blaikie) > > 10. Re: Proposal for ""ll...