search for: stride

Hello, I understand the need for a proper stride setting when formatting a filesystem on a RAID device. However, is there any problem in using a stride setting when formatting a filesystem on a regular non-RAID, non-SSD, just plain-vanilla-single-disk block device? I'm sure there isn't any benefit to it, but I'm curious if there is...

...e Subject properly. Resending with the correct Subject so that the thread is captured properly. -----Original Message----- From: Saito, Hideki Sent: Wednesday, June 15, 2016 1:39 PM To: 'llvm-dev at lists.llvm.org' <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [Proposal][RFC] Strided Memory Access Ashutosh, First, I'm all for enabling general stride load/store support for all targets --- should be just a matter of proper cost modeling. For that matter, we should enable general gather/scatter support for all targets. About the specific approach taken by this RFC: 1) It&...

...<D.2268>: <D.2270>: { logical(kind=4) D.1708; D.2271 = xy.data; D.2272 = (integer(kind=8)) i; D.2273 = (integer(kind=8)) k; D.2274 = xy.dim[2].stride; D.2275 = D.2273 * D.2274; D.2276 = (integer(kind=8)) j; D.2277 = xy.dim[1].stride; D.2278 = D.2276 * D.2277; D.2279 = D.2275 + D.2278; D.2280 = D.2272 + D.2279;...

...nstream doesn't change the big picture. There is certainly a tradeoff against "if vectorizer does this, we'll lose some other optimization downstream" even if vectorizer is the best place to perform a certain optimization ---- but this isn't a new problem. As Ashutosh wrote, stride memref optimization in this RFC can be done later in compilation, and doing so should not be much more complex than doing it in vectorizer. That's why I recommend doing it outside of vectorizer (like CG prepare), and I'm glad to hear that Ashutosh is considering that. Thanks for reading. H...

...Ashutosh > -----Original Message----- > From: Saito, Hideki [mailto:hideki.saito at intel.com] > Sent: Saturday, June 18, 2016 6:00 AM > To: Nema, Ashutosh <Ashutosh.Nema at amd.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: RE: [llvm-dev] [Proposal][RFC] Strided Memory Access Vectorization > > > >Vectorizer's output should be as clean as vector code can be so that analyses > and optimizers downstream can > >do a great job optimizing. > > Guess I should clarify this philosophical position of mine. In terms of vector > c...

...on cases where the relocations applied to alternate words, and >> that totally wrecked the scheme (a bunch of entries with delta==16 and >> count==1). > > > For the same issue in a different context, I recently implemented a scheme using run-length-encoding but using a variable stride. So for a run of alternate words, you still get a single entry, but with stride 16 instead of 8. In my application, most cases of strides > 8 are a run of only 2 or 3 but there are a few cases of dozens or hundreds with a stride of 16. My case is a solution tailored to exactly one application...

...ogle.com; renato.golin at linaro.org; mssimpso at codeaurora.org; kv.bhat at samsung.com; Shahid, Asghar-ahmad <Asghar-ahmad.Shahid at amd.com>; sanjoy at playingwithpointers.com; mzolotukhin at apple.com; Michael Kuperstein <mkuper at google.com> Subject: RE: [llvm-dev] [Proposal][RFC] Strided Memory Access Vectorization One common concern raised for cases where Loop Vectorizer generate bigger types than target supported: Based on VF currently we check the cost and generate the expected set of instruction[s] for bigger type. It has two challenges for bigger types cost is not always co...

...s/gpu/drm/bochs/bochs.h @@ -86,7 +86,7 @@ void bochs_hw_setmode(struct bochs_device *bochs, void bochs_hw_setformat(struct bochs_device *bochs, const struct drm_format_info *format); void bochs_hw_setbase(struct bochs_device *bochs, - int x, int y, u64 addr); + int x, int y, int stride, u64 addr); int bochs_hw_load_edid(struct bochs_device *bochs); /* bochs_mm.c */ diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index 791ab2f79947..ebfea8744fe6 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -255,16 +255...

...nux): FAIL: test/CodeGen/X86/fold-mul-lohi.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc -march=x86-64 | not grep lea leaq B, %rsi leaq A, %r8 leaq P, %rsi child process exited abnormally FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll Failed with exit(1) at line 2 while running: llvm-as < test/CodeGen/X86/stride-nine-with-base-reg.ll | llc -march=x86-64 | not grep lea leaq B, %rdx leaq A, %r8 leaq P, %rdx child process exited abnormally FAIL: test/CodeGen/X86/stride-reuse...

Hi, is there any place where the possible values for the strides in the yuv_buffer structure is specified? or just in the source code? ;) I could compress a video with, lets say, yuvbuf.y_stride = yuvbuf.y_width, so the yuvbuf.y[0] really started in the start of the y channel data. I watched the video in several players, and everythings' ok. But, when prog...

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original Message----- From: David

...lohi.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - > march=x86-64 | not grep lea > leaq B, %rsi > leaq A, %r8 > leaq P, %rsi > child process exited abnormally > FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll > Failed with exit(1) at line 2 > while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- > reg.ll | llc -march=x86-64 | not grep lea > leaq B, %rdx > leaq A, %r8 > leaq P, %rdx > child process exited abnormally &...

Hi, I am trying to educate myself on prefetching/readahead algorithm for Lustre''s read. For a starter I only have two simple questions. 1 - Does Lustre detect linear or random I/O pattern or it always triggers readahead? 2 - If readahead is triggered, how many pages are read in addition to what is necessary? Thanks, Arifa.

...ree.c b/src/gallium/drivers/nv30/nv30_miptree.c index 5a9a63b..9700fa8 100644 --- a/src/gallium/drivers/nv30/nv30_miptree.c +++ b/src/gallium/drivers/nv30/nv30_miptree.c @@ -56,8 +56,7 @@ nv30_miptree_get_handle(struct pipe_screen *pscreen, if (!mt || !mt->base.bo) return FALSE; - stride = util_format_get_stride(mt->base.base.format, - mt->base.base.width0); + stride = mt->level[0].pitch; return nouveau_screen_bo_get_handle(pscreen, mt->base.bo, stride, handle); } diff --git a/src/gallium/drivers/nv50/nv50_miptree.c b/src/galli...

All, I have a question about calculating the value for the -E stride option to mke2fs. The mke2fs man page says stride=stripe-size Configure the filesystem for a RAID array with stripe-size filesystem blocks per stripe. So stride = size of stripe/blocksize. The size of a stripe is the RAID chunk size * the number of drives in the RAID. My que...

...exit(1) at line 2 >> while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - >> march=x86-64 | not grep lea >> leaq B, %rsi >> leaq A, %r8 >> leaq P, %rsi >> child process exited abnormally >> FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll >> Failed with exit(1) at line 2 >> while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- >> reg.ll | llc -march=x86-64 | not grep lea >> leaq B, %rdx >> leaq A, %r8 >> leaq P, %rdx >> child pro...

...te: > A reduction is something like: > > for (i= …) { > r+= a[i]; > } > return r; > Ok, so "reduction" is just a reduction in the map-reduce sense, and nothing else. You don’t need to transform them in the legality phase. Believe me ;). Look > at how we handle stride one pointer inductions at the moment (they are also > memory phis) - they are based off a canonical induction variable that we > create during the actual vectorization. Everything before that is done > virtually without having to transform code until we actually know we want > to vector...

...t;> while running: llvm-as < test/CodeGen/X86/fold-mul-lohi.ll | llc - >>> march=x86-64 | not grep lea >>> leaq B, %rsi >>> leaq A, %r8 >>> leaq P, %rsi >>> child process exited abnormally >>> FAIL: test/CodeGen/X86/stride-nine-with-base-reg.ll >>> Failed with exit(1) at line 2 >>> while running: llvm-as < test/CodeGen/X86/stride-nine-with-base- >>> reg.ll | llc -march=x86-64 | not grep lea >>> leaq B, %rdx >>> leaq A, %r8 >>> leaq P, %r...

...isten = ''78.xxx.xxx.xxx'' vcpus = 2 # number of cpu''s to assign stdvga = 0 serial = ''pty'' usbdevice = ''tablet'' # Required for USB mouse on_reboot = ''restart'' on_crash = ''restart'' Thanks Jake -- Jake Stride Find out more http://about.me/jakestride or follow me on twitter @jake. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users

On 23 October 2013 16:05, Arnold Schwaighofer <aschwaighofer at apple.com>wrote: > In the examples you gave there are no reduction variables in the loop > vectorizer’s sense. But, they all have memory accesses that are strided. > This is what I don't get. As far as I understood, a reduction variable is the one that aggregates the computation done by the loop, and is used outside the loop. In my example, I'm aggregating a computation in an array and returning this array for later use, what am I missing here?...