Thanks, Elena. Committed as r214314, r214315 and r214316. On Jul 29, 2014, at 11:54 PM, Demikhovsky, Elena <[email protected]> wrote:
> Ok. > > - Elena > > From: Adam Nemet [mailto:[email protected]] > Sent: Wednesday, July 30, 2014 04:52 > To: Demikhovsky, Elena > Cc: Craig Topper ([email protected]) > Subject: Re: [PATCH][AVX512] More intrinsics not requiring new backend support > > On Jul 29, 2014, at 12:43 PM, Adam Nemet <[email protected]> wrote: > > > On Jul 29, 2014, at 12:36 PM, Demikhovsky, Elena > > <[email protected]> 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:[email protected]] > >> 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 > >> <[email protected]> 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:[email protected]] > >>> Sent: Tuesday, July 29, 2014 19:57 > >>> To: Demikhovsky, Elena > >>> Cc: [email protected] > >>> Subject: Re: [PATCH][AVX512] More intrinsics not requiring new backend > >>> support > >>> > >>> > >>> On Jul 29, 2014, at 6:35 AM, Demikhovsky, Elena > >>> <[email protected]> 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:[email protected]] > >>>> Sent: Tuesday, July 29, 2014 10:11 > >>>> To: Demikhovsky, Elena > >>>> Cc: [email protected] > >>>> 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
