search for: jan_sjodin

We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns. Why is VFMADDSD4 defined with vector types? Is this simply because the gcc intrinsic uses vector types? It's quite unnatural if you have a compiler that generates FMAs as opposed to requiring user intrinsics. -Dave

...VFMADDSD in my example for VADDSD or whatever you like. I have a lion's share of such a change implemented already and performance is greatly affected. If the community is interested in this change, I would be happy to prepare a patch. -Cameron On Thu, Jul 26, 2012 at 2:27 PM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > You can't execute FMA4 instructions on Intel processors, so it doesn't > really matter what the impact of the move instructions would be, since it > would end up with an illegal instruction regardless. :) It does perhaps > bring up an issue of tuning f...

...DSD or whatever you like. > > I have a lion's share of such a change implemented already and performance is greatly affected. If the community is interested in this change, I would be happy to prepare a patch. > > -Cameron > > On Thu, Jul 26, 2012 at 2:27 PM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > You can't execute FMA4 instructions on Intel processors, so it doesn't really matter what the impact of the move instructions would be, since it would end up with an illegal instruction regardless. :) It does perhaps bring up an issue of tuning for different arc...

Better be quick! I am adding FMA4 and XOP now, and if you contribute code before I do, you can spare yourself some XOP merging. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Benjamin Kramer <benny.kra at googlemail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Thursday, December 1, 2011 12:19 PM > Subject: Re: [LLVMdev]

Jan Sjodin <jan_sjodin at yahoo.com> writes: > Better be quick! I am adding FMA4 and XOP now, and if you contribute > code before I do, you can spare yourself some XOP merging. Go ahead. We're not going to get there soon enough. :( -Dave

That is too bad. :(  You can always review the patches, and if you see something that can be done better let me know. - Jan ----- Original Message ----- > From: David A. Greene <greened at obbligato.org> > To: Jan Sjodin <jan_sjodin at yahoo.com> > Cc: David A. Greene <greened at obbligato.org>; Benjamin Kramer <benny.kra at googlemail.com>; "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> > Sent: Thursday, December 1, 2011 2:48 PM > Subject: Re: [LLVMdev] bdver1 cpu(bulldozer) support...

On 2 May 2012 16:57, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > 8th will work for me. Can we pick a place that is not overly noisy? http://www.harbordhouse.ca should be fine, but let us know if you have another suggestion. > - Jan > Cheers, Rafael

8th will work for me. Can we pick a place that is not overly noisy? - Jan >________________________________ > From: Rafael Espíndola <rafael.espindola at gmail.com> >To: Ehsan Akhgari <ehsan.akhgari at gmail.com> >Cc: Jeff Muizelaar <jmuizelaar at mozilla.com>; clang-dev Developers <cfe-dev at cs.uiuc.edu>; "Minard, Brian" <brian.minard at

On Sat, Feb 9, 2019 at 4:44 PM Jan Sjodin <jan_sjodin at yahoo.com> wrote: > > The reason I'm looking for solutions that can work without "scanning the > > code" or "spooky action at a distance" is that we should have a solution > > that's easily digestible by folks who are not aware of GPU execution &...

...;, not '///class'). 3. Use doxygen comments when appropriate (for example, on methods, instance variables). I have various comments on MCJITStreamer itself, but I will hold them until we have an individual patch for that class. - Daniel On Wed, Jul 28, 2010 at 10:41 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > This patch contains the initial implementation of MCJIT. > > - Jan > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llv...

This patch contains the initial implementation of MCJIT. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019_mcjit.patch Type: text/x-diff Size: 42198 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100728/2eb6ac65/attachment.patch>

...patches until the MCJITSTreamer has been reviewed and checked in. Thanks, Jan --- On Sat, 8/21/10, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: From: Bruno Cardoso Lopes <bruno.cardoso at gmail.com> Subject: Re: [LLVMdev] MC-JIT Streamer 1/3 To: "Jan Sjodin" <jan_sjodin at yahoo.com> Cc: "Daniel Dunbar" <daniel at zuster.org>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Date: Saturday, August 21, 2010, 8:39 AM Hi Jan, Just a random comment, the indentation in mem_raw_ostream::write_impl and mem_raw_ostream::current_...

...sses the MCJITStreamer uses, and the last patch is the MCJITStreamer class itself. - Jan --- On Sun, 8/1/10, Daniel Dunbar <daniel at zuster.org> wrote: > From: Daniel Dunbar <daniel at zuster.org> > Subject: Re: [LLVMdev] MC-JIT Patches 2/3 > To: "Jan Sjodin" <jan_sjodin at yahoo.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Date: Sunday, August 1, 2010, 6:58 PM > Hi Jan, > > I would rather not work with a patch this large. Can you > pull out the > addition of the MCJITStreamer into its own patch, and...

...whatever you like. > > I have a lion's share of such a change implemented already and performance > is greatly affected. If the community is interested in this change, I would > be happy to prepare a patch. > > -Cameron > > On Thu, Jul 26, 2012 at 2:27 PM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > >> You can't execute FMA4 instructions on Intel processors, so it doesn't >> really matter what the impact of the move instructions would be, since it >> would end up with an illegal instruction regardless. :) It does perhaps >> bring up...

...addsd %xmm3, fp4_+3288(%rip), %xmm0, %xmm3 # fpppp.f:666 I do not know the actual number of cycles offhand, but I believe on Interlagos and Sandybridge, a vmovaps takes roughly 3x as many micro-ops as a vmovsd if it involves memory. -Cameron On Thu, Jul 26, 2012 at 9:41 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > Because the intrinsics uses vector types (same as gcc). > > > - Jan > > > > ----- Original Message ----- > > From: "dag at cray.com" <dag at cray.com> > > To: llvmdev at cs.uiuc.edu > > Cc: > > Sent: Wednesda...

...rlier, then there's no divergence and the merge intrinsic >> is a no-op. > > Makes sense. > > - Jan > On Wednesday, January 30, 2019, 11:41:29 AM EST, Connor Abbott > <cwabbott0 at gmail.com> wrote: > > > On Wed, Jan 30, 2019 at 4:20 PM Jan Sjodin <jan_sjodin at yahoo.com > <mailto:jan_sjodin at yahoo.com>> wrote: > > > > > > > > for (int i = 0; i < 2; i++) { > > > >  foo = ballot(true); // ballot 1 > > > > > > > >    if (threadID /* ID of the thread within...

I have cleaned up the code somewhat that Olivier wrote and split up the patch into three pieces. This first is to make the MCJIT not have to initialize all asm printers, but only the native one. - Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018_nativeasmprinterinit.patch Type: text/x-diff Size: 12993 bytes Desc: not available URL:

...n't happy about the change to add "Target" everywhere -- I just added a local hack in TargetSelect.h to workaround this. We should really change the definition of LLVM_NATIVE_TARGET, but I am not in a configure hacking mood. - Daniel On Wed, Jul 28, 2010 at 10:39 AM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: > I have cleaned up the code somewhat that Olivier wrote and split up the patch into three pieces. This first is to make the MCJIT not have to initialize all asm printers, but only the native one. > > - Jan > > _______________________________________________ &...

Because the intrinsics uses vector types (same as gcc). - Jan ----- Original Message ----- > From: "dag at cray.com" <dag at cray.com> > To: llvmdev at cs.uiuc.edu > Cc: > Sent: Wednesday, July 25, 2012 3:26 PM > Subject: [LLVMdev] X86 FMA4 > > We're migrating to LLVM 3.1 and trying to use the upstream FMA patterns. > > Why is VFMADDSD4

.... >> >> I have a lion's share of such a change implemented already and performance is greatly affected. If the community is interested in this change, I would be happy to prepare a patch. >> >> -Cameron >> >> On Thu, Jul 26, 2012 at 2:27 PM, Jan Sjodin <jan_sjodin at yahoo.com> wrote: >> You can't execute FMA4 instructions on Intel processors, so it doesn't really matter what the impact of the move instructions would be, since it would end up with an illegal instruction regardless. :) It does perhaps bring up an issue of tuning for different...