search for: masked_load

...1:20 To: Demikhovsky, Elena <elena.demikhovsky at intel.com> Cc: Sanjay Patel <spatel at rotateright.com>; Nema, Ashutosh <Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] how to force llvm generate gather intrinsic Hi Elena, Are the masked_load and gather working now? Best, Zhi On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>> wrote: > Can we legalize the same set of masked load/store operations for AVX1 as AVX2? Yes, of course. - Elen...

Hi Elena, Are the masked_load and gather working now? Best, Zhi On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < elena.demikhovsky at intel.com> wrote: > Ø Can we legalize the same set of masked load/store operations for AVX1 > as AVX2? > > Yes, of course. > > > > - * Elena* >...

Thanks Sanjay for highlighting this, few days back I also faced similar problem while generating masked store in avx1 mode, found its only supported under avx2 else we scalarize it. > 1) I did not switch-on masked_load/store to AVX1, I can do this. Yes Elena, This should be supported for FP type in avx1 mode (for INT type, I doubt X86 has masked_load/store instruction in avx1 mode). Thanks, Ashutosh From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Demikhovsky, Elena via llvm-dev Sent: Sa...

...hutosh <Ashutosh.Nema at amd.com<mailto:Ashutosh.Nema at amd.com>> wrote: Thanks Sanjay for highlighting this, few days back I also faced similar problem while generating masked store in avx1 mode, found its only supported under avx2 else we scalarize it. > 1) I did not switch-on masked_load/store to AVX1, I can do this. Yes Elena, This should be supported for FP type in avx1 mode (for INT type, I doubt X86 has masked_load/store instruction in avx1 mode). Thanks everyone for the answers. My immediate motivation is to improve the masked load/store ops for an AVX target. If we can fix...

...gt; > *Cc:* Sanjay Patel <spatel at rotateright.com>; Nema, Ashutosh < > Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> > > *Subject:* Re: [llvm-dev] how to force llvm generate gather intrinsic > > > > Hi Elena, > > > > Are the masked_load and gather working now? > > > > Best, > > Zhi > > > > On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < > elena.demikhovsky at intel.com> wrote: > > Ø Can we legalize the same set of masked load/store operations for AVX1 > as AVX2? > > Yes...

...tateright.com>; Nema, Ashutosh < >> Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> >> >> *Subject:* Re: [llvm-dev] how to force llvm generate gather intrinsic >> >> >> >> Hi Elena, >> >> >> >> Are the masked_load and gather working now? >> >> >> >> Best, >> >> Zhi >> >> >> >> On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < >> elena.demikhovsky at intel.com> wrote: >> >> Ø Can we legalize the same set of masked load/s...

...gt; *Cc:* Sanjay Patel <spatel at rotateright.com>; Nema, Ashutosh < > Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> > > > *Subject:* Re: [llvm-dev] how to force llvm generate gather intrinsic > > > > Hi Elena, > > > > Are the masked_load and gather working now? > > > > Best, > > Zhi > > > > On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < > elena.demikhovsky at intel.com> wrote: > > Ø Can we legalize the same set of masked load/store operations for AVX1 > as AVX2? > > Yes...

...to:spatel at rotateright.com>>; Nema, Ashutosh <Ashutosh.Nema at amd.com<mailto:Ashutosh.Nema at amd.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: Re: [llvm-dev] how to force llvm generate gather intrinsic Hi Elena, Are the masked_load and gather working now? Best, Zhi On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com<mailto:elena.demikhovsky at intel.com>> wrote: > Can we legalize the same set of masked load/store operations for AVX1 as AVX2? Yes, of course. - Elen...

....com>; Nema, Ashutosh < >> Ashutosh.Nema at amd.com>; llvm-dev <llvm-dev at lists.llvm.org> >> >> >> *Subject:* Re: [llvm-dev] how to force llvm generate gather intrinsic >> >> >> >> Hi Elena, >> >> >> >> Are the masked_load and gather working now? >> >> >> >> Best, >> >> Zhi >> >> >> >> On Sat, Jan 23, 2016 at 12:06 PM, Demikhovsky, Elena < >> elena.demikhovsky at intel.com> wrote: >> >> Ø Can we legalize the same set of masked load/s...

Thanks for your response, Sanjay. I know there are intrinsics available in C/C++. But the problem is that I want to instrument my code at the IR level and generate those instructions. I don't want to touch the source code. Best, Zhi On Fri, Jan 22, 2016 at 4:54 PM, Sanjay Patel <spatel at rotateright.com> wrote: > I was just looking at the related masked load/store operations, and

On May 8, 2013, at 4:00 PM, Eric Christopher <echristo at gmail.com> wrote: > > Thinking that a masked store is conservatively a store of the full > width of the store right? It depends on the optimization. Consider this example: masked_store(Val, Ptr , M) X = masked_load(Ptr, M2) If you assume that your store actually overwrites everything in that memory location then you don't need to load that memory location again. You can simply use the stored value. However, in our example X != Val. > But Jim pointed out that anything merging loads would then need to...

...the names for various load/store intrinsics particularly ugly. My personal take: 1) I like the cleaner naming scheme. 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) 3) I have no strong preference other than that the @llvm.masked_load (and friends) intrinsics support alternate address spaces in some form in the near future. What do others think? Philip -------- Forwarded Message -------- Subject: [PATCH] D17497: Support arbitrary address space for intrinsics Date: Mon, 22 Feb 2016 08:39:38 +0000 From: Elena Demikhovsky...

...gt; ugly. >> >> My personal take: >> 1) I like the cleaner naming scheme. >> 2) I'm not sure the additional complexity is worth it. (Not specific >> to the particular implementation proposed here.) >> 3) I have no strong preference other than that the @llvm.masked_load >> (and friends) intrinsics support alternate address spaces in some >> form in the near future. >> >> What do others think? >> >> Philip >> >> >> -------- Forwarded Message -------- >> Subject: [PATCH] D17497: Support arbitrary address...

.../store intrinsics particularly ugly. > > My personal take: > 1) I like the cleaner naming scheme. > 2) I'm not sure the additional complexity is worth it. (Not specific to the particular implementation proposed here.) > 3) I have no strong preference other than that the @llvm.masked_load (and friends) intrinsics support alternate address spaces in some form in the near future. > > What do others think? > > Philip > > > -------- Forwarded Message -------- > Subject: [PATCH] D17497: Support arbitrary address space for intrinsics > Date: Mon, 22 Feb 2016...

On Wed, May 8, 2013 at 3:31 PM, Nadav Rotem <nrotem at apple.com> wrote: > > On May 8, 2013, at 1:59 PM, Eric Christopher <echristo at gmail.com> wrote: > > I can almost see that, but how is the intrinsic any different from a > conservative width for stores/loads where they're not handled by an > optimization pass? I'm assuming I'm missing something here.

On May 8, 2013, at 1:59 PM, Eric Christopher <echristo at gmail.com> wrote: > I can almost see that, but how is the intrinsic any different from a > conservative width for stores/loads where they're not handled by an > optimization pass? I'm assuming I'm missing something here. > > -eric I don't understand what you mean by "conservative width".

...013, at 4:00 PM, Eric Christopher <echristo at gmail.com> wrote: > > > Thinking that a masked store is conservatively a store of the full > width of the store right? > > > It depends on the optimization. Consider this example: > > masked_store(Val, Ptr , M) > X = masked_load(Ptr, M2) > > If you assume that your store actually overwrites everything in that > memory location then you don't need to load that memory location again. You > can simply use the stored value. However, in our example X != Val. > I'm not sure I understand the full impact of...