similar to: [LLVMdev] Alignment of constant loads

On Fri, September 12, 2008 11:33 am, Stefanus Du Toit wrote: > Hi, > > We've noticed that constant loads, e.g. of v4f32 types, are not > aligned to the preferred alignment but rather to the ABI alignment, at > least on x86. On x86 targets it's usually 16 for both preferred and ABI. I guess you're using a target with a lower ABI alignment for vectors? > This seems to

Hi Nicolas, On 2-Apr-09, at 6:04 PM, Nicolas Capens wrote: > Thanks for verifying this. Could you patch this or should I open a > new bug report and find a generic solution first? I don't have write access so the best I could do would be to submit a patch, and I'm crazy busy at the moment. I actually think the check I described below is fine and would fix this bug (but

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 way to fix this would be to use:

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 or are you also doing any late (e.g.,

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

Hot on the heels of our LLVM product announcement earlier today, we have just announced a new compiler development position at RapidMind. This position will involve working directly with and on LLVM and other compiler technologies. If you're interested, please email us your resume at jobs at rapidmind.com. If you have specific experience working with, or contributing to, LLVM, please

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

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

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 Toit <stefanus.dutoit at rapidmind.com> > RapidMind Inc. > phone: +1

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

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 -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

On 4-May-09, at 4:15 PM, OvermindDL1 wrote: > Actually, I am *very* curious if this is the bug. I can try to see if > it is now that I know what to look for (or if you fix it in SVN then I > will first make sure the bug still exists in mine, when it does then I > will update LLVM to the latest trunk and test again, if it was fixed > that I will be giving many thanks), but the

Hi Oscar, On 30-Jul-08, at 9:41 AM, Óscar Fuentes wrote: > 1. General LLVM users: Are you so happy with `configure' and hand-made > makefiles that you wont consider an alternative? If you are > interested, > I can steer my work to cover all platforms. We (RapidMind) are very interested. We would very much like to see a unified build system across MSVC/Windows and gcc/Linux/OS

From http://www.llvm.org/docs/TestingGuide.html#quickdejagnu : To run only a subdirectory of tests in llvm/test using DejaGNU (ie. Transforms), just set the TESTSUITE variable to the path of the subdirectory (relative to llvm/test): % gmake TESTSUITE=Transforms check On 17-Jun-09, at 1:33 PM, Aaron Gray wrote: > Does 'make check' allow just running on a particualar directory of

Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes

Hi Oscar, On 10-Oct-08, at 4:44 PM, Óscar Fuentes wrote: > I could add that to my CMake build system TODO, but so far I'm a bit > skeptic about LLVM relevance on the non-Unix world. The Windows build > can be broken for a long period before anyone notices. The VS2003 > support is broken since a long time ago and, apart from myself, no > other > user cares. Seems that LLVM

On 30-Jul-09, at 8:54 PM, Eli Friedman wrote: > On Thu, Jul 30, 2009 at 5:32 PM, Peter Shugalev<peter at shugalev.com> > wrote: >> Though the most problematic stuff is the lack of 'shadow zone' >> support >> in Win64 ABI. Or maybe I haven't figured out how to turn this on. In >> Win64 any function can treat 32 bytes of stack (RSP+08h..RSP+28h

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

Hi David, On 30-Apr-09, at 6:59 PM, David Greene wrote: > This is not scalable. > > So what I've done is a little experiment to see if I can unify all > SSE and AVX > SIMD instructions under one framework. I'll leave MMX and 3dNow > alone since > they're oddballs and hardly anyone uses them. I don't want to unnecessarily expand your scope, but while

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 <ty>> <v1>, <n x <ty>> <v2>, <m x i32> > <mask> ; yields <m x <ty>> > > The