similar to: [LLVMdev] 3.4.1 Release Plans

On Mar 3, 2015, at 11:08 PM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 3 March 2015 at 21:59, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at vidyo.com>> wrote: Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I

On 30 January 2015 at 02:41, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Zhongwei Yao wrote: >> Hi, all, >> >> Does Opus need celt_pitch_xcorr? s fixed point version for ARM aarch64 >> architecture? If yes, which version does Opus prefer: assembly or >> instrinsics? > > It would be nice to have one. I don't have a lot of experience with

Hello Jonathan, Just FYI, I started doing review of your patch and will get back to you in few days. After review, I would like to rebase your patch (as necessary) myself and do some testing.. and re-submit. Regards, Vish On 4 March 2015 at 09:00, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 3 March 2015 at 22:17, Jonathan Lennox <jonathan at

Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I mentioned in the IRC room a problem I discovered in creating my patch, and then later improved the fix Tim had made for the problem. Where do you get conflicts merging it to tip? In terms of merging, you posted your patch before I posted mine, so probably I should be

On Thu, Apr 17, 2014 at 09:57:32AM -0400, Tom Stellard wrote: > On Fri, Apr 11, 2014 at 03:02:21PM -0700, Tom Stellard wrote: > > Hi, > > > > I have just tagged the first release candidate for the > > 3.4.1 release, so testers may begin testing. Please refer to > > http://llvm.org/docs/ReleaseProcess.html for information on how to > > validate a release.

Hello Hal, I am not very familiar with the DSP capabilities of PowerPC, but I imagine there will be instructions for simple vector operations like vector addition, multiplication, etc. so for these I imagine the implementation would consist of just outputting the correct instruction. However, for NEON instructions like the reciprocal step (see

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

Hi, I have just tagged the first release candidate for the 3.4.1 release, so testers may begin testing. Please refer to http://llvm.org/docs/ReleaseProcess.html for information on how to validate a release. If you have any questions or need something clarified, just email the list. For the 3.4.1 release we want to compare test results against 3.4-final. I have added support to the

Speaking of conversion, do we actually have Neon code for int<->float conversion? Jean-Marc On 01/02/15 05:26 PM, Timothy B. Terriberry wrote: > Viswanath Puttagunta wrote: >> Could you please elaborate on "It would be nice to have"? Specifically: >> - Are there use cases where fixed point is preferred when AAarch64 has >> mandatory support for floating

Hi there, I am Software product developer at Robert Bosch, Germany. We are using armv8 64bit targets for our development. We have the need to do the cross compiling for our target on windows. I have compiled clang 5.0 from the vcs git. I have tried compiling the code with following options set: clang.exe -target armv8 -fslp-vectorize-aggressive -mfpu=neon -mfloat-abi=hard -c test.cpp As you

Hi, all, Does Opus need celt_pitch_xcorr' s fixed point version for ARM aarch64 architecture? If yes, which version does Opus prefer: assembly or instrinsics? Thanks, Zhongwei -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the

> On Nov 16, 2015, at 4:42 PM, Jonathan Lennox <jonathan at vidyo.com> wrote: > > I haven?t yet tried replacing SIG2WORD16 (or silk_ADD_SAT32/silk_SUB_SAT32) with Neon intrinsics. That?s an obvious next step. This doesn?t show any appreciable speed difference in my tests, but the code is obviously better by inspection (all three of these map directly to a single Aarch64

Hi GlobalISel interested parties, A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose

On 25 November 2014 at 10:11, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com> wrote: > > > > On Nov 25, 2014, at 10:07 AM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > >> > >> > Also is there plans to make the NEON optimisations

Hello LLVM Devs, I am starting my PhD on Automatic Parallelization for DSP and want to play with some ARM NEON intrinsics for a start. I spent the last three days trying to compile a version of LLVM that would allow me to compile sources that contain these intrinsics, but with no success. In the process I found out that clang doesn't support NEON (as per

--- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index f52d2c2..e1a6e9b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,7 +190,7 @@ AC_ARG_ENABLE([rtcd], [enable_rtcd=yes]) AC_ARG_ENABLE([intrinsics], - [AS_HELP_STRING([--disable-intrinsics], [Disable intrinsics optimizations for ARM(float) X86(fixed)])],, +

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

Stan, Do you mean that you want to emulate the ARM NEON intrinsics on PowerPC? -Hal ----- Original Message ----- > > > Hello LLVM Devs, > > > Thanks for helping me previously to cross-compile for ARM, I managed > to get a working toolchain and am currently having fun compiling > different toy problems and running them on a pandaboard. > > As part of my

Hello LLVM Devs, Thanks for helping me previously to cross-compile for ARM, I managed to get a working toolchain and am currently having fun compiling different toy problems and running them on a pandaboard. As part of my research I am trying to implement the ARM NEON Intrinsics in the PowerPC LLVM backend. I am still at the beginning of my efforts and am not yet familiar with either the ARM or

--- configure.ac | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/configure.ac b/configure.ac index 90a06c8..adcb969 100644 --- a/configure.ac +++ b/configure.ac @@ -503,6 +503,26 @@ AS_IF([test x"$enable_intrinsics" = x"yes"],[ [rtcd_support="$rtcd_support (NE10)"]) ]) + OPUS_CHECK_INTRINSICS( +