search for: stefanus

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

...atch for this in my spare time since I haven't hacked on LLVM in a while, but if you're interested in doing it let me know. In any case, the one- line patch (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-Ap...

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. 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-bo...

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. 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? Good point! One easy...

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

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

...n be lifted out. What'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 UR...

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

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 > > -- > Stefan...

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

Hi Stefanus, I'm not if using MMX instructions when doing operations on 64-bit vectors is so terrible? With x86-64 you have double the registers, but it comes at the cost of longer instruction encodings. So there's probably no benefit using SSE. Or am I missing something? Cheers, Nicolas -----Orig...

...ze() == Mask.size(), because LHSMask.size() == LHS->getNumElements() == Mask.size(). It shouldn't be too hard to relax the constraint that this optimization requires the number of elements being shuffle to be equal to the mask size, but it'll probably take some careful testing! Stefanus -- 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/20090401/a892b529/attach...

On May 1, 2009, at 3:40 PM, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular poi...

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 tran...

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

...SE3 is available. 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

...into the tag bits of the Uses, but I can't see an easy way to do this. I'd appreciate your thoughts. In the meantime I will probably commit some additional comments for Use.cpp to make the code a bit easier to understand, as well as putting an assert in place to catch this earlier. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

Hi all, I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug: if (Mask[i] >= 2*e) NewMask.push_back(2*e); else NewMask.push_back(LHSMask[Mask[i]]); When Mask[i] is bigger than the size of LHSMask it reads out of bounds on that last line. I believe the first line is there to try to prevent that but then it

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 gen...

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 somethi...