similar to: [LLVMdev] LLVM Conference 2007 ?

LLVMers, The LLVM Oversight group is trying to assess whether there is sufficient interest in the LLVM development community for holding an LLVM Conference next summer. If getting together with your fellow LLVM Developers sounds interesting to you, please respond to me (off list) and I'll summarize the results. Here's our current thinking: * Venue: West Coast, USA. Probably either San

FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default. I could be misremembering which compilers do this though :) This flag allows you to make all kinds of nice simplfiying assumptions about floating point. On Thu, Jan 8, 2009 at 7:45 PM, Owen Anderson <resistor at mac.com> wrote: > I assume it checks that the end condition and the increment can both > be

> On May 26, 2015, at 1:37 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> >> On 2015-May-26, at 09:46, Alex L <arphaman at gmail.com> wrote: >> >> Hi all, >> >> The CodeGen library is a big bag of interdependent bits. This caused >> a circular dependency in the MIR serialization commit (r237954), which got >>

Thanks for many comments. The loop with finite fp values(which could be representable in IEEE754 fp format) such like, void foo() { float i; for (i = 0.0f; i < 1000.0f; i += 1.2f) { } } could reach the end condition under any fp rounding mode, and eliminating the loop has no side effects. (for example, floating point control register does not change because the increment does

On 10/21/2011 09:28 AM, Owen Anderson wrote: > Reed, > > On Oct 20, 2011, at 9:47 AM, Reed Kotler wrote: >> I would like to see the many adhoc parsers in LLVM get replaced by ones >> generated from grammars. > > FYI, this is very unlikely to happen. The parsers in LLVM /were/ > historically generated from grammars (bison, as I recall), and those >

> On May 16, 2015, at 12:21 PM, Liu, Yaxun (Sam) <Yaxun.Liu at amd.com> wrote: > > I am thinking maybe the functionality of the bi-way conversion can be kept at llvm/lib/Bitcode/SPIRV, which will facilitate OpenCL vendors to do conversions between LLVM and SPIR-V. On the other hand, we create a llvm/Target/SPIR-V, which uses llvm/lib/Bitcode/SPIRV to generate SPIR-V. The SPIR-V

On Oct 17, 2009, at 1:32 AM, Owen Anderson wrote: > Chris, > > On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote: >> Unfortunately, we found out at the last minute that Apple has a rule >> which prevents its engineers from giving video taped talks or >> distributing slides. We will hold onto the video and slide assets in >> case this rule changes in the future.

+1. Could those two be subdirectories of one “Machine-Related-Stuff” directory? E.g., MachineStuff/IR MachineStuff/CodeGen Where MachineStuff is something meaningful :). That way, they keep a logic bound, more formal than the naming convention. My 2c. Q. > On May 26, 2015, at 9:28 PM, Chris Lattner <clattner at apple.com> wrote: > > On May 26, 2015, at 1:46 PM, Owen Anderson

Alright, go ahead with it. —Owen > On Nov 17, 2014, at 4:58 AM, Daniil Troshkov <troshkovdanil at gmail.com> wrote: > > Hi! > > I have not found test case. (It is because we have no target using "ExpandInsertToVectorThroughStack"). > But I tested it for target currently not included in llvm trunk. > > This fix correct and trivial, so I'm offering

Chris, On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote: > Unfortunately, we found out at the last minute that Apple has a rule > which prevents its engineers from giving video taped talks or > distributing slides. We will hold onto the video and slide assets in > case this rule changes in the future. While I'm glad to know we all share similar sentiments on this, lots of

I assume it checks that the end condition and the increment can both be represented precisely with integer types. --Owen On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote: > Isn't "simplifying" the loop index to an integer also dependent on > precision issues? The following loop is infinite: > > for (float i=0.0; i<...; i+=1.0) {} > > where ... is a large

What would you do with a just-hardware memory fence? If the compiler's free to move operations over the hardware fence, that seems to defeat the purpose. C++0X provides a compiler-only fence, and a hardware+compiler fence, but no hardware-only fence, I believe for this reason. See <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf>, section 29.8. On Sat, May 16, 2009 at

Surprisingly enough, libatomic_ops doesn't define just a hardware memory fence call as far as I can tell. --Owen On May 16, 2009, at 3:00 PM, Zoltan Varga wrote: > Hi, > > You might want to use this: > > http://www.hpl.hp.com/research/linux/atomic_ops/ > > Zoltan > > On Sat, May 16, 2009 at 11:11 PM, Owen Anderson <resistor at

--- On Tue, 2/3/09, Owen Anderson <resistor at mac.com> wrote: > From: Owen Anderson <resistor at mac.com> > Subject: Re: [LLVMdev] rol/ror llvm instruction set > To: kasra_n500 at yahoo.com, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Date: Tuesday, February 3, 2009, 4:20 PM > On Feb 3, 2009, at 3:54 PM, Kasra wrote: > > I guess the

I detected this bug using test case from platform which is not currently supported on llvm targets. (Our team is porting llvm on new target). Creating the test case will take some extra time. I'll try to do it ASAP. Have you any ideas about the test case? (targets using ExpandInsertToVectorThroughStack, etc...) On Wed, Nov 12, 2014 at 8:29 PM, Owen Anderson <resistor at mac.com> wrote:

Jeffrey Yasskin wrote: > What would you do with a just-hardware memory fence? If the compiler's > free to move operations over the hardware fence, that seems to defeat > the purpose. If your compiler memory fence (gcc's __sync_synchronize()) doesn't distinguish different kinds of fencing requirements, and your platform has different hardware fences with different costs

r2->replaceAllUsesWith(r1); r2->eraseFromParent(); LLVM makes it easy! ;-) --Owen On Nov 15, 2008, at 11:02 PM, Karhu, Abhinav R wrote: > Hi owen, > Can you please elaborate as to what should I do? Find all the > instruction which have r2 in it and replace all of them with r1 and > then remove the load instruction? > Thanks > Abhinav > ----- Original Message

Hi owen, Can you please elaborate as to what should I do? Find all the instruction which have r2 in it and replace all of them with r1 and then remove the load instruction? Thanks Abhinav ----- Original Message ----- From: "Owen Anderson" <resistor at mac.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, November 14, 2008 11:22:32 PM

Owen Anderson <resistor at mac.com> writes: > On Jul 26, 2008, at 7:56 PM, Óscar Fuentes wrote: >> Having a private branch would be handy for some experiments I'm >> doing. Two years ago there was an announcement by Owen Anderson, but >> the repo seems down now. > > I haven't maintained that for a long time. I think there are some > community members

No, that should work fine, and is exactly what I use to compile atomics on Darwin. --Owen On May 23, 2009, at 11:02 PM, Xi Wang wrote: > Thanks. I think I am using Apple GCC 4.2. > > i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566) > > Should I use something else for LLVM? > > - xi > > On Sun, May 24, 2009 at 1:20 AM, Owen Anderson <resistor at