search for: toit

Hi Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: Hi Stefanus, Thanks for the info. I still think it's a bug though. Take for example a case where the vectors each have four elements...

...atch (plus a test case, and probably an assert to do the bounds check in debug mode) would probably be worthwhile to do right away. Stefanus > > Cheers, > > Nicolas > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit > Sent: woensdag 1 april 2009 18:59 > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Shuffle combine > > On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: > Hi Stefanus, > > Thanks for the info. I still think it’s a bug though. Take for > example a case where t...

...the code owner for the x86 backend. Michael has been a very frequent contributor to the x86 backend for the last few months, and is working on the x86 backend full-time. Note that Michael is out of the office until Nov 29 with very limited email/internet access. Thanks, Stefanus -- Stefanus Du Toit <stefanus.du.toit at intel.com> Intel Waterloo Phone: 519-591-1738

For those curious about uses of LLVM, we just officially announced our adoption of LLVM in our products: http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php Thanks for all the support so far on here, we look forward to continuing to work with LLVM! -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

...e where the vectors each have four elements. The values in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. So LHSMask[Mask[i]] can go out of bounds, no? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 16:31 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine Hi Nicolas, On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug:...

The llvm-dev archives (and other llvm/clang mailing list archives) on the web don't seem to have any new messages since some time Monday night. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

...The code could also be improved to consider the new mask equal to lhsmask/mask in places where they both refer to undefined elements. Stefanus > Cheers, > > Nicolas > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev- > bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit > Sent: woensdag 1 april 2009 16:31 > To: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Shuffle combine > > Hi Nicolas, > > On 1-Apr-09, at 7:34 AM, Nicolas Capens wrote: > I’m having some trouble understanding the following lines in > InstructionCombining.cpp,...

I would like to nominate Nadav Rotem for the x86 backend. Michael On Nov 15, 2012, at 10:51 AM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 15, 2012, at 7:45 AM, "Du Toit, Stefanus" <stefanus.du.toit at intel.com> wrote: > >> I'd like to propose that Michael Liao become the code owner for the x86 backend. >> >> Michael has been a very frequent contributor to the x86 backend for the last few months, and is working on the x86 back...

On 30-Jan-09, at 6:14 PM, Eli Friedman wrote: > On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit > <stefanus.dutoit at rapidmind.com> wrote: >> The computation of %base then becomes loop-invariant and can be >> lifted out. >> >> What's the best way to add this optimization to LLVM? > > Probably the best place is LICM itself... only loop transformati...

On Nov 10, 2008, at 12:01 PM, Stefanus Du Toit wrote: > For those curious about uses of LLVM, we just officially announced our > adoption of LLVM in our products: > > http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php I'm thrilled to read an official announcement of that! Do you use LLVM only for static code generation...

Stefanus Du Toit wrote: > The llvm-dev archives (and other llvm/clang mailing list archives) on > the web don't seem to have any new messages since some time Monday > night. > It seems to be working for me. Does it work for you now? -- John T. > Stefanus > > -- > Stefanus Du To...

On Nov 15, 2012, at 7:45 AM, "Du Toit, Stefanus" <stefanus.du.toit at intel.com> wrote: > I'd like to propose that Michael Liao become the code owner for the x86 backend. > > Michael has been a very frequent contributor to the x86 backend for the last few months, and is working on the x86 backend full-time. &g...

...t;LLVM Social". If you need any help, call me at 519-496-4224. Thanks to everyone who participated in the Doodle poll. We should have a good turnout of at least ten or so LLVM enthusiasts! Stefanus [1] 59 King St N, Waterloo, ON, N2J 2X2 - at the corner of King and Princess. -- Stefanus Du Toit <stefanus.du.toit at intel.com> Intel Waterloo

On 21-Jul-08, at 7:33 PM, Eli Friedman wrote: > On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit > <stefanus.dutoit at rapidmind.com> wrote: >> 1) Vector shl, lshr, ashr >> > I have a rough draft of a patch for this that works reasonably well > for simple cases... I don't think I really have the time to finish it > properly, but I'll clean it up a bit and...

...; backward, I’m seeing a MachineInstr with opcode MOV32rm and > NumOperands equal to 6 (which is 5 in earlier revisions). I’m not > sure if this actually helps explain the bug but it’s one of the > weird things that happen with revision 67979 and subsequent revisions… -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090501/82133c08/attachment.html>

...#39;s the best way to add this optimization to LLVM? Should the reassociate pass be made aware of GEPs somehow? Note that the transformation also involves turning an add into a GEP, so I'm not sure reassociate is the right place. Suggestions appreciated! Thanks, Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463 -------------- next part -------------- A non-text attachment was scrubbed... Name: addind.c Type: application/octet-stream Size: 271 bytes Desc: not available URL: <http://lists.l...

Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to

...able. Is this really the intent or is it just that SSE versions of certain patterns have not been added, and therefore it falls back to MMX versions? It's not really encouraged to use MMX (or x87 for that matter) on modern microarchitectures if you can get away with SSE. -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

I agree further generalization seems like a very good idea. But I'd like to see what Mon Ping proposed implemented first so we have a better idea of the implementation cost. Thanks, Evan On Sep 30, 2008, at 6:44 AM, Stefanus Du Toit wrote: > Hi Mon Ping, > > Generalizing shufflevector would be great. I have an additional > suggestion below. > > On 29-Sep-08, at 11:11 PM, Mon Ping Wang wrote: >> I am proposing to extend the shuffle vector definition to be >> <result> = shufflevector <n x...

On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > The computation of %base then becomes loop-invariant and can be lifted out. > > What's the best way to add this optimization to LLVM? Probably the best place is LICM itself... only loop transformations are aware whether something is lo...