[PATCH][AVX512] More intrinsics not requiring new backend support

[Adam Nemet]

Thanks, Elena.  Committed as r214314, r214315 and r214316.

On Jul 29, 2014, at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:

> Ok.
>  
> -           Elena
>  
> From: Adam Nemet [mailto:anemet at apple.com] 
> Sent: Wednesday, July 30, 2014 04:52
> To: Demikhovsky, Elena
> Cc: Craig Topper (craig.topper at gmail.com)
> Subject: Re: [PATCH][AVX512] More intrinsics not requiring new backend support
>  
> On Jul 29, 2014, at 12:43 PM, Adam Nemet <anemet at apple.com> wrote:
> 
> > On Jul 29, 2014, at 12:36 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:
> > 
> >> Somebody who uses compiler intrinsics expects to receive the "best" solution. The broadcast instruction exactly fits this requirement.
> >> If you want to use the generic pattern, please add a lit test for LLVM that guarantees one broadcast at the end. 
> > 
> > I can certainly do that, thanks!
> 
> It’s r214275 in llvm.
> 
> I’d like to commit the three intrinsic patches after this unless you have something else you would like me to do.
> 
> One change in the set1 patch is that as it turns out epi8 and epi16 are actually part of AVX512BW/VL so those don’t belong in 512F.  I removed them from the patch.   New version of the patches is attached.
> 
> Thanks,
> Adam
> 
> > 
> > Adam
> > 
> >> 
> >> -  Elena
> >> 
> >> 
> >> -----Original Message-----
> >> From: Adam Nemet [mailto:anemet at apple.com] 
> >> Sent: Tuesday, July 29, 2014 22:22
> >> To: Demikhovsky, Elena
> >> Subject: Re: [PATCH][AVX512] More intrinsics not requiring new backend support
> >> 
> >> 
> >> On Jul 29, 2014, at 12:10 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:
> >> 
> >>> I'd prefer broadcast, it guarantees best solution. 
> >> 
> >> Can you please elaborate why you think so?  I think Craig Topper and others have expressed preference to use generic constructs rather than machine intrinsics in these cases.  As I said, this is what the AVX headers do...
> >> 
> >> Adam
> >> 
> >>> 
> >>> -  Elena    
> >>> 
> >>> 
> >>> -----Original Message-----
> >>> From: Adam Nemet [mailto:anemet at apple.com]
> >>> Sent: Tuesday, July 29, 2014 19:57
> >>> To: Demikhovsky, Elena
> >>> Cc: cfe-commits at cs.uiuc.edu
> >>> Subject: Re: [PATCH][AVX512] More intrinsics not requiring new backend 
> >>> support
> >>> 
> >>> 
> >>> On Jul 29, 2014, at 6:35 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote:
> >>> 
> >>>> Hi Adam,
> >>>> 
> >>>> 1)
> >>>> set1_pd, set1_ps, set1_epi64, set1_epi32 should be implemented as broadcast.
> >>>> 
> >>>> 2)
> >>>> I don't understand in "casts".
> >>> 
> >>> Hi Elena,
> >>> 
> >>> I should have mentioned in the log that both set1 and the casts are widened versions of their counterparts in AVX (see avxintrin.h).
> >>> 
> >>> In particular for set1 and any other op that can be implemented without machine intrinsics, that is usually the preferred way (see r22c5bf6 in clang for an example).  This allows them to be recognized and optimized by the machine-independent optimization passes.  
> >>> 
> >>>> 3)
> >>>> __builtin_ia32_knothi receives unsigned short It should look like
> >>>> 
> >>>> BUILTIN(__builtin_ia32_knothi, "Us", "")  instead of
> >>>> +BUILTIN(__builtin_ia32_knothi, "ss", "")
> >>> 
> >>> Good catch, thanks.  I will change this to UsUs.
> >>> 
> >>> Please let me know if you're OK with the patches after this fix and with the additional comment above.
> >>> 
> >>> Thanks,
> >>> Adam
> >>> 
> >>>> 
> >>>> -  Elena
> >>>> 
> >>>> 
> >>>> -----Original Message-----
> >>>> From: Adam Nemet [mailto:anemet at apple.com]
> >>>> Sent: Tuesday, July 29, 2014 10:11
> >>>> To: Demikhovsky, Elena
> >>>> Cc: cfe-commits at cs.uiuc.edu
> >>>> Subject: [PATCH][AVX512] More intrinsics not requiring new backend 
> >>>> support
> >>>> 
> >>>> Hi Elena,
> >>>> 
> >>>> Please let me know if these look good to you.
> >>>> 
> >>>> Thanks,
> >>>> Adam
> >>>> 
> >>>> ---------------------------------------------------------------------
> >>>> Intel Israel (74) Limited
> >>>> 
> >>>> This e-mail and any attachments may contain confidential material for 
> >>>> the sole use of the intended recipient(s). Any review or distribution 
> >>>> by others is strictly prohibited. If you are not the intended 
> >>>> recipient, please contact the sender and delete all copies.
> >>>> 
> >>> 
> >>> ---------------------------------------------------------------------
> >>> Intel Israel (74) Limited
> >>> 
> >>> This e-mail and any attachments may contain confidential material for 
> >>> the sole use of the intended recipient(s). Any review or distribution 
> >>> by others is strictly prohibited. If you are not the intended 
> >>> recipient, please contact the sender and delete all copies.
> >>> 
> >> 
> >> ---------------------------------------------------------------------
> >> Intel Israel (74) Limited
> >> 
> >> This e-mail and any attachments may contain confidential material for
> >> the sole use of the intended recipient(s). Any review or distribution
> >> by others is strictly prohibited. If you are not the intended
> >> recipient, please contact the sender and delete all copies.
> >> 
> >
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140730/e19df12d/attachment.html>