similar to: __ARM_FEATURE_DOTPROD for AArch32

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 13402 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180424/9d3e655d/attachment-0001.gif>

optimizations done for this CPU architecture. Whether it is in-line assembly or assembly optimization of function (Eg: celt_pitch_xcorr_arm.s), or using intrinsics, it is still some optimizations. So, I don't understand your perspective. I really thought about this for the most amount of time... could you please suggest an alternative here?.. Because I'm really out of ideas in this area

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values

Hi all, Actually,I found there is a same problem for arm.For this case,I think > maybe we can play a trick in the clang. > Checking whether the given arch valid or not,before we throw it to the > parser,which can be used for both arm > and aarch64. For the actions I mentioned above,I wrote a check function as below, basing on the naming rules of the arm architecture. +//Only if

Hi, At the last EuroLLVM, I gave a lightning talk about code review statistics on Phabricator reviews and what we could derive from that to try and reduce waiting-for-review bottlenecks. (see https://llvm.org/devmtg/2018-04/talks.html#Lightning_2). One of the items I pointed to is a script we've been using internally for a little while to try and match open Phabricator reviews to people who

I just saw this, and I have to say -- thanks, Kristof! Do you know if this is something that could be automated in Phabricator, instead of something that people run on their own? Or is the intent of this to be something that ran regularly (say, weekly or daily) that would email people (or the list) that could be doing the reviews for some of the open patches? On Sat, Apr 28, 2018 at 1:01 AM,

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Renato,

On Nov 25, 2014, at 11:13 AM, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 25 November 2014 at 10:11, Viswanath Puttagunta <viswanath.puttagunta at linaro.org<mailto:viswanath.puttagunta at linaro.org>> wrote: On 25 November 2014 at 09:39, Jonathan Lennox <jonathan at vidyo.com<mailto:jonathan at

On 5 May 2016 at 13:01, Bradley Smith <Bradley.Smith at arm.com> wrote: > Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used > for specifying an architecture version to target whereas aarch64/arm64 don’t > convey any information to that effect, does it mean armv8a, armv8.1-a, etc? Hi Bradley, That's a good point. But also, what does "armv8a"

On 25 November 2014 at 10:18, Jonathan Lennox <jonathan at vidyo.com> wrote: > > On Nov 25, 2014, at 11:13 AM, Viswanath Puttagunta > <viswanath.puttagunta at linaro.org> wrote: > > 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

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and several loop-vectorization

On Mon, Oct 10, 2016 at 1:14 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 10 October 2016 at 19:39, Alina Sbirlea <alina.sbirlea at gmail.com> > wrote: > > Now, for ARM archs Halide is currently generating explicit VSTn > intrinsics, > > with some of the patterns I described, and I found no reason why Halide > > shouldn't generate a single

To give an update here, we actually are not missing a mapping. The code complains because we are copying around a fp16 into a gpr32 and that shouldn’t be done with a copy (default mapping). I extended the repairing code to issue G_ANYEXT in those cases instead of asserting. However, now, I have to teach instruction select about those ANYEXT otherwise we’ll fallback in that case. But that’s a

Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. >

Thanks for the summary, some more comments inline. On 1 February 2017 at 22:02, Renato Golin <renato.golin at linaro.org> wrote: > On 1 February 2017 at 21:22, Saito, Hideki <hideki.saito at intel.com> wrote: >> I think we are converging enough at the detail level, but having a big >> difference in the opinions at the "vision" level. :) > > Vision is

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 on ARMv7 run time >> > detectable like they have in cairo/pixman? For generic distributions >> > it would nice to

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

Hi, I am working on C/C++ language support for the Armv8.2-A half-precision instructions. I've added support for _Float16 as a new source language type to Clang. _Float16 is a C11 extension type for which arithmetic is well defined, as opposed to e.g. __fp16 which is a storage-only type. I then fixed up the AArch64 backend, which was mostly straightforward: this involved making operations