search for: rl263446

Displaying 4 results from an estimated 4 matches for "rl263446".

2016 Mar 16
3
the as-if rule / perf vs. security
...to eliminate some of the variables you have rightfully > cited. > > Let's assume we're not dealing with volatiles, atomics, or FP operands. > We'll even guarantee that the extra loaded value is never used. This is, in > fact, the scenario that <http://reviews.llvm.org/rL263446> > http://reviews.llvm.org/rL263446 is concerned with. > > Related C example: > > typedef int v4i32 __attribute__((__vector_size__(16))); > > // Load some almost-consecutive ints as a vector. > v4i32 foo(int *x) { > int x0 = x[0]; > int x1 = x[1]; > // int...
2016 Mar 16
3
the as-if rule / perf vs. security
...row the scope of the problem to eliminate some of the variables you have rightfully cited. Let's assume we're not dealing with volatiles, atomics, or FP operands. We'll even guarantee that the extra loaded value is never used. This is, in fact, the scenario that http://reviews.llvm.org/rL263446 is concerned with. Related C example: typedef int v4i32 __attribute__((__vector_size__(16))); // Load some almost-consecutive ints as a vector. v4i32 foo(int *x) { int x0 = x[0]; int x1 = x[1]; // int x2 = x[2]; // U can't touch this? int x3 = x[3]; return (v4i32) { x0, x1, 0,...
2016 Mar 15
3
the as-if rule / perf vs. security
...; *Sent:* Monday, March 14, 2016 10:37 PM > *To:* Nema, Ashutosh > *Cc:* llvm-dev > *Subject:* Re: [llvm-dev] masked-load endpoints optimization > > > > I checked in a patch to do this transform for x86-only for now: > http://reviews.llvm.org/D18094 / http://reviews.llvm.org/rL263446 > > > > On Fri, Mar 11, 2016 at 9:57 AM, Sanjay Patel <spatel at rotateright.com> > wrote: > > Thanks, Ashutosh. > > Yes, either TTI or TLI could be used to limit the transform if we do it in > CGP rather than the DAG. > > The real question I have is whethe...
2016 Mar 11
3
masked-load endpoints optimization
Thanks, Ashutosh. Yes, either TTI or TLI could be used to limit the transform if we do it in CGP rather than the DAG. The real question I have is whether it is legal to read the extra memory, regardless of whether this is a masked load or something else. Note that the x86 backend already does this, so either my proposal is ok for x86, or we're already doing an illegal optimization: define