similar to: [LLVMdev] LLVM 2.2 Release Notes

On Feb 10, 2008, at 12:25 AM, Chris Lattner wrote: > Hi All, > > The first draft of the llvm 2.2 release notes are now available: > http://llvm.org/docs/ReleaseNotes.html > > The release is scheduled for Monday, so please take a look at them and > send me your feedback, or (better yet) just commit fixes directly to > the document in llvm/docs/ReleaseNotes.html. In

> This is a matter of presentation, but some of the "GCC extensions" are > standard C99 (now, at least). I noticed long long, C++-style comments > and designated initializers. > > I have plenty of complaints about the GCC documentation you're > pointing at, but this probably isn't the right forum for that. I do > think dropping "as fast as

On Feb 10, 2008, at 11:26 PM, Chris Lattner wrote: >> This is a matter of presentation, but some of the "GCC extensions" >> are >> standard C99 (now, at least). I noticed long long, C++-style >> comments >> and designated initializers. >> >> I have plenty of complaints about the GCC documentation you're >> pointing at, but this

Hi all, I'm working on a graphics project which uses LLVM for dynamic code generation, and I noticed a major performance regression when upgrading from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it entirely). I found out that the performance regression is due to removing support for lowering 64-bit vector operations to MMX, and using SSE2 instead. My code uses a

On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > Hi all, > > I'm working on a graphics project which uses LLVM for dynamic code > generation, and I noticed a major performance regression when upgrading > from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I skipped it > entirely). > > I found out that the performance regression is due to removing

Hi Bill, Comments inline: On 24/10/2011 9:50 PM, Bill Wendling wrote: > On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: > >> Hi all, >> >> I'm working on a graphics project which uses LLVM for dynamic code >> generation, and I noticed a major performance regression when upgrading >> from LLVM 2.8 to 3.0-rc1 (LLVM 2.9 didn't support Win64 so I

On Sep 7, 2010, at 7:45 AM, Nicolas Capens wrote: > Hi all, > > I've tested a recent revision and noticed that using 64-bit vectors became very slow. It looks like they are expanded to non-MMX instructions to avoid breaking code which does not clear the MMX state using emms? > > For my project I'm already manually inserting emms instructions in the right places, so

On Mon, Aug 31, 2020 at 3:02 PM Eli Friedman <efriedma at quicinc.com> wrote: > Broadly speaking, I see two problems with implicitly enabling MMX > emulation on a target that has SSE2: > > > > 1. The interaction with inline asm. Inline asm can still have MMX > operands/results/clobbers, and can still put the processor in MMX mode. If > code is mixing MMX

I recently diagnosed a bug in someone else's software, which turned out to be due to incorrect MMX intrinsics usage: if you use any of the x86 intrinsics that accept or return __m64 values, then you, the *programmer* are required to call _mm_empty() before using any x87 floating point instructions or leaving the function. I was aware that this was required at the assembly-level, but not that

On Sep 8, 2010, at 7:24 AM, Eli Friedman wrote: > On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens > <nicolas.capens at gmail.com> wrote: >> Hi Chris, >> >> It's not broken, but the performance is crippled. >> >> I noticed that the code still contains some MMX instructions, but several >> operations get expanded (apparently swizzling and such

On Apr 14, 2011, at 12:47 PM, Eli Friedman wrote: >> I looked at the program using a debugger, and the pfadd instruction is >> executed correctly and the MMX register contains the correct values. >> The code that prepares the stack for the printf call seems to be >> messing it up. > > I would call that "user error"; basically, using MMX instructions >

On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote: > > Hi Argiris, > > The real problem here is that the X86 backend is turning datatypes like <1 x i64> into MMX operations, but doesn't do so in a safe way (it's not inserting the requisite EMMS instructions). After discussing this with Dale and Bill, the right fix is to stop mapping generic vectors onto MMX operations.

On Aug 31, 2010, at 11:18 AM, Argyrios Kyrtzidis wrote: > Hi, > > I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it

Hi, I've attached 2 .ll files which are supposed to be equivalent but 'unopt-fail.ll' causes a crash in webkit's test suite while 'unopt-pass.ll' does not. I can't give more details about the crash, when I run the crashing test it in isolation it passes, when I run the full suite it crashes; it boggles the mind. Below I provide the optimized asm that is produced from

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to

On Oct 26, 2011, at 1:18 PM, Nicolas Capens wrote: > On 24/10/2011 9:50 PM, Bill Wendling wrote: >> On Oct 20, 2011, at 8:42 AM, Nicolas Capens wrote: >> >>> Hi all, >>> >>> I'm working on a graphics project which uses LLVM for dynamic code >>> generation, and I noticed a major performance regression when upgrading >>> from LLVM

On Sep 1, 2010, at 9:43 AM, Bob Wilson wrote: > > On Aug 31, 2010, at 10:19 PM, Chris Lattner wrote: >> >> Hi Argiris, >> >> The real problem here is that the X86 backend is turning datatypes like <1 x i64> into MMX operations, but doesn't do so in a safe way (it's not inserting the requisite EMMS instructions). After discussing this with Dale and

Hi Nicolas, > I found out that the performance regression is due to removing support > for lowering 64-bit vector operations to MMX, and using SSE2 instead. My > code uses a mix of MMX intrinsics and v4i16 operations, so it ping-pongs > back and forth between MMX and SSE2 instructions in the generated code. > > To get more optimal code, I see three options, and I was wondering

On Thu, Apr 14, 2011 at 5:37 PM, Chris Lattner <clattner at apple.com> wrote: > > On Apr 14, 2011, at 12:47 PM, Eli Friedman wrote: > >>> I looked at the program using a debugger, and the pfadd instruction is >>> executed correctly and the MMX register contains the correct values. >>> The code that prepares the stack for the printf call seems to be

Please take a look: http://llvm.org/docs/ReleaseNotes.html -Chris -- http://nondot.org/sabre/ http://llvm.org/