search for: vector_width

...en/arch/x86/acpi/power.c Wed Jan 28 21:56:22 2009 -0800 +++ b/xen/arch/x86/acpi/power.c Wed Jan 28 22:09:02 2009 -0800 @@ -129,19 +129,13 @@ static void acpi_sleep_prepare(u32 state wakeup_vector_va = __acpi_map_table( acpi_sinfo.wakeup_vector, sizeof(uint64_t)); - if ( acpi_sinfo.vector_width == 32 ) - { - *(uint32_t *)wakeup_vector_va = - tboot_in_measured_env() ? - (uint32_t)g_tboot_shared->s3_tb_wakeup_entry : - (uint32_t)bootsym_phys(wakeup_start); - } - else - { - *(uint64_t *)wakeup_vector_va = -...

...refer to *the* original > loop, not just any llvm.loop metadata with the same child metadata. > So it should look like: !0 = metadata !{ metadata !0, metadata !1, metadata !2 } !1 = metadata !{ metadata !"llvm.loop.parallel" } !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } Correct? paul > On dropping the llvm.loop.parallel metadata and relying only on checking the parallel_loop_access to identify parallel loops, I'm not so sure. Does it > retain all the info for all cases? Let's say you have a parallel loop without > memory accesses...

On 05/23/2013 06:52 PM, Redmond, Paul wrote: > I'm not even sure you would need the llvm.loop.parallel anymore since the > vectorizer could just look to see if the loop id on a parallel_loop_access > matches the loop id of the loop being vectorized. > > Does this make any sense? Yes. However, I think you still need use the self-referencing metadata trick or similar to make the

On May 23, 2013, at 8:52 AM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > > !0 = metadata !{ metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } > > I'm not even sure you would need the llvm.loop.parallel anymore since the vectorizer could just look to see if the loop id on a parallel_loop_access matches the loop id of the loop being vectorized. > > Does this make any sense? > Yes. It makes sense to m...

...m.loop.parallel to llvm.loop and making the hints child nodes? e.g., br i1 %exitcond, label %loop.end, label %loop.body, !llvm.loop !0 ... !0 = metadata !{ metadata !1, metadata !2 } !1 = metadata !{ metadata !"llvm.loop.parallel" } !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } I'm not even sure you would need the llvm.loop.parallel anymore since the vectorizer could just look to see if the loop id on a parallel_loop_access matches the loop id of the loop being vectorized. Does this make any sense? > > If we decide, that > > #pragma iv...

Hi Michael and Florian, ( + llvm-dev for visibility) I would like to quickly follow up on "Pragma vectorize_width() implies vectorize(enable)", which got reverted with commit 858a1ae for 2 reasons, see also that revert commit message. Ignore the assert, that's been fixed now. The other thing is that with the patch behaviour is slightly changed and we could get a diagnostic we

...use the LoopVectorize pass is not even in the pipeline -- and we cannot be more specific in the message. However, -Rpass-missed=loop-vectorize may give more information. > The additional warning makes sense to me and I think is also beneficial to the user. > > Before, we silently ignored vector_width() in the example [1] and I suppose the user was expecting vectorize_width(4) to be honored. Now we are more transparent in informing the user what is happening: we were not able to honor their requested pragma and I assume they would be interested in knowing. As already mentioned, the loop indeed...

On May 23, 2013, at 9:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 23 May 2013 14:52, Arnold Schwaighofer <aschwaighofer at apple.com> wrote: > I would like us to grow a few annotations, among others, one to force vectorization irrespective whether the loop vectorizer thinks it is beneficial or not - however, this is future music. > > Isn't that part

...wrote: > > On May 23, 2013, at 8:52 AM, "Redmond, Paul" <paul.redmond at intel.com> > wrote: > > > !0 = metadata !{ metadata !1, metadata !2 } > !1 = metadata !{ metadata !"llvm.loop.parallel" } > !2 = metadata !{ metadata !"llvm.vectorization.vector_width", i32 8 } > > I'm not even sure you would need the llvm.loop.parallel anymore since the > vectorizer could just look to see if the loop id on a parallel_loop_access > matches the loop id of the loop being vectorized. > > Does this make any sense? > > > > Yes....