similar to: [LLVMdev] Alignment of constant loads

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Alignment of constant loads"

2008 Sep 13
2
[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
2009 Apr 03
0
[LLVMdev] Shuffle combine
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
2009 Apr 01
0
[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. 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:
2008 Nov 10
0
[LLVMdev] RapidMind/LLVM Announcement
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.,
2009 Apr 02
2
[LLVMdev] Shuffle combine
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
2008 Nov 10
0
[LLVMdev] LLVM-related compiler position at RapidMind
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
2008 Jul 22
2
[LLVMdev] Extending vector operations
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
2009 Mar 12
2
[LLVMdev] List archives not updating
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
2009 Mar 12
0
[LLVMdev] List archives not updating
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
2008 Nov 10
3
[LLVMdev] RapidMind/LLVM Announcement
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
2008 Aug 01
1
[LLVMdev] Generating movq2dq using IRBuilder
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
2009 May 04
0
[LLVMdev] PointerIntPair causing trouble
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
2008 Jul 30
0
[LLVMdev] Is there room for another build system?
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
2009 Jun 17
0
[LLVMdev] how do I run 'make check' on say just the 'test/CodeGen' directory ?
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
2009 Jan 30
2
[LLVMdev] Reassociating expressions involving GEPs
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
2008 Oct 10
0
[LLVMdev] 2.4 Pre-release (v1) Available for Testing
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
2009 Jul 31
2
[LLVMdev] Win64 bugs
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
2009 Feb 25
4
[LLVMdev] Reassociating expressions involving GEPs
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
2009 May 01
0
[LLVMdev] RFC: AVX Pattern Specification [LONG]
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
2008 Sep 30
0
[LLVMdev] Generalizing shuffle vector
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