similar to: [LLVMdev] inefficient code generation for 128-bit->256-bit typecast intrinsics

On Sun, 5 Jul 2015 14:59:54 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > On Sun, Jul 05, 2015 at 12:58:53PM +0200, Michael S. Tsirkin wrote: > > On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > > > The virtio_ring.h header is used in userspace programs (ie. QEMU), > > > too. Here we can not assume that sizeof(pointer) is the same

The virtio_ring.h header is used in userspace programs (ie. QEMU), too. Here we can not assume that sizeof(pointer) is the same as sizeof(long), e.g. when compiling for Windows, so the typecast in vring_init() should be done with (uintptr_t) instead of (unsigned long). This fixes a compiler warning when compiling QEMU with the mingw32 cross-compiler. Signed-off-by: Thomas Huth <thuth at

On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > The virtio_ring.h header is used in userspace programs (ie. QEMU), > too. Here we can not assume that sizeof(pointer) is the same as > sizeof(long), e.g. when compiling for Windows, so the typecast in > vring_init() should be done with (uintptr_t) instead of (unsigned long). > > Signed-off-by: Thomas Huth <thuth

The virtio_ring.h header is used in userspace programs (ie. QEMU), too. Here we can not assume that sizeof(pointer) is the same as sizeof(long), e.g. when compiling for Windows, so the typecast in vring_init() should be done with (uintptr_t) instead of (unsigned long). This fixes a compiler warning when compiling QEMU with the mingw32 cross-compiler. Signed-off-by: Thomas Huth <thuth at

On Mon, Jul 06, 2015 at 11:24:42AM +0200, Thomas Huth wrote: > On Sun, 5 Jul 2015 14:59:54 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Sun, Jul 05, 2015 at 12:58:53PM +0200, Michael S. Tsirkin wrote: > > > On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > > > > The virtio_ring.h header is used in userspace

On Mon, Jul 06, 2015 at 11:24:42AM +0200, Thomas Huth wrote: > On Sun, 5 Jul 2015 14:59:54 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > On Sun, Jul 05, 2015 at 12:58:53PM +0200, Michael S. Tsirkin wrote: > > > On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > > > > The virtio_ring.h header is used in userspace

The virtio_ring.h header is used in userspace programs (ie. QEMU), too. Here we can not assume that sizeof(pointer) is the same as sizeof(long), e.g. when compiling for Windows, so the typecast in vring_init() should be done with (uintptr_t) instead of (unsigned long). Signed-off-by: Thomas Huth <thuth at redhat.com> --- include/uapi/linux/virtio_ring.h | 2 +- 1 file changed, 1

The virtio_ring.h header is used in userspace programs (ie. QEMU), too. Here we can not assume that sizeof(pointer) is the same as sizeof(long), e.g. when compiling for Windows, so the typecast in vring_init() should be done with (uintptr_t) instead of (unsigned long). Signed-off-by: Thomas Huth <thuth at redhat.com> --- include/uapi/linux/virtio_ring.h | 2 +- 1 file changed, 1

Hello, Currently if you have a string column that have only number values (think a year column using string by mistake) and you want to change to integer, you can''t. If you apply this monkey-patch will be possible: https://gist.github.com/1393441 Note: if some value can''t be casted by postgresql (if have a letter for example), the migration will fail as expected. I think

On Sun, Jul 05, 2015 at 12:58:53PM +0200, Michael S. Tsirkin wrote: > On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > > The virtio_ring.h header is used in userspace programs (ie. QEMU), > > too. Here we can not assume that sizeof(pointer) is the same as > > sizeof(long), e.g. when compiling for Windows, so the typecast in > > vring_init() should be done

On Sun, Jul 05, 2015 at 12:58:53PM +0200, Michael S. Tsirkin wrote: > On Thu, Jul 02, 2015 at 09:21:22AM +0200, Thomas Huth wrote: > > The virtio_ring.h header is used in userspace programs (ie. QEMU), > > too. Here we can not assume that sizeof(pointer) is the same as > > sizeof(long), e.g. when compiling for Windows, so the typecast in > > vring_init() should be done

> I'm not sure I understand the full impact of this example, and I would like to. > > What are the desired memory model semantics for a masked store? Specifically, let me suppose a simplified vector model of <2 x i64> on an i64-word-size platform. > Hi Chandler, I brought the example in this email thread to show that the optimizations that we currently have won't

On Thu, May 9, 2013 at 1:09 AM, Nadav Rotem <nrotem at apple.com> wrote: > 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 =

On 01/28/2013 06:51 PM, Hal Finkel wrote: > Is this sufficient to implement #pragma ivdep in clang? I'm not completely sure of this: "Note: The proven dependencies that prevent vectorization are not ignored, only assumed dependencies are ignored."

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

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Pekka Jääskeläinen" <pekka.jaaskelainen at tut.fi> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Monday, January 28, 2013 10:45:36 AM > Subject: Re: [LLVMdev] [PATCH] parallel loop awareness to the LoopVectorizer > > Hi Pekka,

About these disclaimers associated with ivdep and such... You guys are overthinking it. They're just saying you cannot force the compiler to vectorize or parallelize a loop that it knows (can prove!) is not a parallel loop. They are not obliging the compiler to do dependence analysis or alias analysis or anything. For example len = 0; while (A[i]) { i++; len++; } Assert all you want;

I have 2 radio buttons like this: <%= radio_button ''group'', ''public'', true %> <%= radio_button ''group'', ''public'', false %> They hold the correct values when viewing the @group object. However, when updating, it does not appear that the params[:group][:public] value is being typecast correctly. As

I want to typecast an object of HashWithIndifferentAccess (params) to Hash. Whats the way of doing this (except each?) Thanks in advance. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails

The AVX saga continues. I am attempting to write a pattern for VEXTRACTF128 but am having some problems. My attempt looks something like this: defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst,