similar to: X86 backend code ownership

Thanks for the support Nadav, Zvi, Chandler, Renato, and anyone else I missed. Quetin, to maybe address your concerns. My focus lately has been fixing inconsistency in instruction selection behavior between the older AVX instruction encodings and the new AVX512 encodings. I've also been trying to fix cases where concepts haven't been extended to wider vectors yet. For instance, the

+1 - especially since I think Craig convinced Intel that LLVM isn't just a hobby project for him. :) On Thu, Nov 10, 2016 at 5:08 AM, Andrea Di Biagio via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Fwiw, I also think that Craig would be a good code owner. So, my +1 goes > to him :-) > > @Nadav, thanks again for all your kind help and contributions to the x86 >

Alright, works for me then! Q. > On Nov 10, 2016, at 10:43 AM, Michael Kuperstein via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > +1 > > On Thu, Nov 10, 2016 at 7:15 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > +1 - especially since I think Craig convinced Intel that LLVM isn't just a hobby

Hi Quentin,  Thank you for bringing this up. I planned to finish the discussion on the vectorizer before starting the discussion on the X86 backed code ownership, but now is a good time. Simon, Sanjay, Craig, Elena, Bruno, Michael, Andrea, Chandler have made significant contributions to the X86 backend in the last few years. I think that Craig Topper would be a great code owner, assuming he wants

On 9 Nov 2016 06:04, "Chandler Carruth via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > Just my two cents, but if Craig is up for it, I think this would be a pretty great fit. +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161108/9a73b9e1/attachment.html>

+1 Thanks Nadav for your help over the last few years! Andrea On Mon, Nov 7, 2016 at 9:20 PM, Matthew Simpson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +1 > > -- Matt > > On Sun, Nov 6, 2016 at 1:00 AM, Nadav Rotem via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> It been a while since I worked on the vectorizers and I think that it's

Hi Frank, > > To answer Nadav's question. This kind of loop is generated by a scientific library and we are in the process of evaluating whether LLVM can be used for this research project. The target architectures will have (very wide) vector instructions and these loops are performance-critical to the application. Thus it would be important that these loops can make use of the vector

It been a while since I worked on the vectorizers and I think that it's time for someone else to be the code owner. During the conference I talked about this with Arnold and a few other people who were involved in the development of the vectorizers. Based on these discussions I recommend Michael Kuperstein. Michael is committed to improving LLVM and has lots of relevant experience. If approved

Hi Nadav, We are looking at a variety of target architectures. Ultimately we aim to run on BG/Q and Intel Xeon Phi (native). However, running on those architectures with the LLVM technology is planned in some future. As a first step we would target vanilla x86 with SSE/AVX 128/256 as a proof-of-concept. Most of our generated functions implement pure data-parallel operations which suit

This is almost ideal for SLP vectorization, except for two problems: 1. We have 4 stores to consecutive locations, but the last element is the constant zero, and not an additional SUB. At the moment we don’t have support for idempotence operations, but this is something that we should add. 2. The values that we are subtracting come from 3 loads. We usually load 4 elements from memory, or

Hi Frank, > We are looking at a variety of target architectures. Ultimately we aim to run on BG/Q and Intel Xeon Phi (native). However, running on those architectures with the LLVM technology is planned in some future. As a first step we would target vanilla x86 with SSE/AVX 128/256 as a proof-of-concept. Great! It should be easy to support these targets. When you said wide-vectors I assumed

Hi , In the future, we will address this issue. Regards Michael Zuckerman From: Eric Christopher [mailto:echristo at gmail.com] Sent: Sunday, May 01, 2016 19:54 To: Zuckerman, Michael <michael.zuckerman at intel.com>; Craig Topper <craig.topper at gmail.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa

Hi, For now no. But I will add this three builtins to CGBuiltin.cpp. If you want, you can be a reviewer of this change. Regards Michael Zuckerman From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Thursday, April 28, 2016 04:53 To: Zuckerman, Michael <michael.zuckerman at intel.com> Subject: Re: r267690 - [Clang][BuiltIn][AVX512]Adding intrinsics for vmovntdqa vmovntpd vmovntps

Thank you. I'm letting it auto detect by setting the target using getProcessTarget. I disabled avx512 support by passing -avx512f (and the other variants) to setMAttrs on EngineBuilder. I can see refs to avx512 in X86.td. It's the exact same executable running on Kabylake. What does the Cannot select: specifically mean? Is there some table that doesn't have a definition for a key in

getProcessTriple just determines operation system, and architecture. It doesn't deal with specific instruction set features. The CPU should be controlled by MCPU on the EngineBuilder i think. The CPU autodetection code lives in getHostCPUName in lib/Support/Host.cpp, but I don't think the JIT calls into. I think its expected the user would call it or pass a specific CPU string to the MCPU

> On Oct 24, 2014, at 10:57 AM, Adam Nemet <anemet at apple.com> wrote: > > On Oct 24, 2014, at 4:24 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com <mailto:elena.demikhovsky at intel.com>> wrote: > >> Hi, >> >> We would like to add support for masked vector loads and stores by introducing new target-independent intrinsics. The loop

I haven't looked into actually implementing revectorization, so we may just want to ignore that possibility for now. But I imagined that revectorization could hit the same problem that we're trying to avoid here: if the cost models say that wider vectors are legal and cheaper, but the reality is that perf will suffer when using those wider vectors, then we want to avoid using the wider

On Sat, Nov 11, 2017 at 8:52 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/11/2017 09:52 PM, UE US via llvm-dev wrote: > > If skylake is that bad at AVX2 > > > I don't think this says anything negative about AVX2, but AVX-512. > > it belongs in -mcpu / -march IMO. > > > No. We'd still want to enable the architectural

On 11/13/2017 05:49 PM, Eric Christopher wrote: > > > On Mon, Nov 13, 2017 at 2:15 PM Craig Topper via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Sat, Nov 11, 2017 at 8:52 PM, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On

If skylake is that bad at AVX2 it belongs in -mcpu / -march IMO. Most people will build for the standard x86_64-pc-linux or whatever anyway, and completely ignore the change. This will mainly affect those who build their own software and optimize for their system, and lots there have probably caught on to this already. I always thought that's what -march was made for, really. GNOMETOYS