[llvm-dev] X86 backend code ownership

[Chandler Carruth via llvm-dev]

As a final point, I think there are very few (if any) people who have deep
knowledge of *all* of the x86 backend at this point. Being a code owner
shouldn't be predicated on that. Whomever it is can always reach out to the
other major contributors to other parts of the backend as necessary.

On Thu, Nov 10, 2016 at 1:34 PM Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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> wrote:
>
> +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
> backend!
>
> -Andrea
>
> On Thu, Nov 10, 2016 at 3:20 AM, Craig Topper via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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 instcombine handling of x86 shift intrinsics. I've also been
> trying to remove AVX512 intrinsics for things that can be represented with
> native IR or where we can use a legacy instrinsic and only need a masking
> IR select instruction to support AVX512.
>
> ~Craig
>
> On Wed, Nov 9, 2016 at 5:38 PM, Quentin Colombet via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Copy/pasting my concerns here to ease the reading:
> Craig is indeed one of the main contributor of the X86 backend (in terms
> of commits). My concern though is that Craig’s focus is on the assembly
> (TableGen classes clean-up and such) and not so much on CodeGen (ISel and
> various X86-specific passes) as far as I can tell.
>
> > On Nov 9, 2016, at 5:11 PM, Nadav Rotem via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I'd like to continue the discussion on the X86 backend ownership that
> started here [1].  I think that Craig Topper would be a great code owner.
> Several people replied to the email with +1s. Quentin had some concerns.
> Let's continue the discussion.
> >
> > -Nadav
> >
> >
> >
> > [1] - http://lists.llvm.org/pipermail/llvm-dev/2016-November/106931.html
> .
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161111/0b0c731e/attachment.html>