search for: firsty

Displaying 12 results from an estimated 12 matches for "firsty".

Did you mean: first
2016 Aug 25
2
InstList insert depreciated?
Jon, > You want: > TaintVar->insertAfter(FirstI); This worked! Thank you. On Thu, Aug 25, 2016 at 9:38 AM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > > > On 8/25/16 7:01 AM, Shehbaz Jaffer via llvm-dev wrote: >> >> I tried an alternative way of adding instruction by first getting the >> first instruction of the basic block, and then
2013 Nov 01
6
[LLVMdev] Vectorization of loops with conditional dereferencing
Nadav, Arnold, et al., I have a number of loops that I would like us to be able to autovectorize (common, for example, in n-body inter-particle force kernels), and the problem is that they look like this: for (int i = 0; i < N; ++i) { if (r[i] > 0) v += m[i]*...; } where, as written, m[i] is not accessed unless the condition is true. The general problem (as is noted by the loop
2016 Aug 25
2
InstList insert depreciated?
Hi llvm-devel, I have migrated my codebase from llvm-3.6 to llvm 3.8.1-stable. Although I was able to resolve most of the problems, I am facing issues resolving the following: To insert an instruction immediately after the first instruction within a basic block, I first get all instructions in my basic block in an instruction container list. Once that is done, I insert my new instruction in the
2013 Nov 01
0
[LLVMdev] Vectorization of loops with conditional dereferencing
Hi Hal, Yes, I agree that this is a problem that prevents vectorization in many loops. Another problem that we have is that sunk loads don’t preserve their control dependence properties. For example in the code below, if we sink the load into the branch then we can't vectorize the loop. x = A[i] if (cond) { sum += x; } I agree with you that checking the first and last element for each
2013 Nov 14
0
[LLVMdev] Vectorization of loops with conditional dereferencing
On 1 November 2013 13:40, Hal Finkel <hfinkel at anl.gov> wrote: > Done = false; > FirstI = -1, LastI = -1; > while (!Done) { > for (I = FirstI+1; I < N; ++I) > if (r[i] > 0) { > FirstI = I; > break; > } > > for (; I < N && !page_bound(&m[i]) && ...; ++I) { > if (r[i] > 0) > LastI = I; >
2013 Nov 01
1
[LLVMdev] Vectorization of loops with conditional dereferencing
----- Original Message ----- > Hi Hal, > > Yes, I agree that this is a problem that prevents vectorization in > many loops. Another problem that we have is that sunk loads don’t > preserve their control dependence properties. For example in the > code below, if we sink the load into the branch then we can't > vectorize the loop. > > x = A[i] > if (cond) { >
2013 Nov 14
3
[LLVMdev] Vectorization of loops with conditional dereferencing
I think that the best way to move forward with the vectorization of this loop is to make progress on the vectorization pragmas. The LoopVectorizer is already prepared for handling pragmas and we just need to add the clang-side support. Is anyone planning to work on this ? On Nov 14, 2013, at 2:18 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 1 November 2013 13:40, Hal
2006 Jun 05
5
Controller-wide instance variable
Is it possible to declare an instance variable in a controller that is available to every action without defining the variable in every action? -- Posted via http://www.ruby-forum.com/.
2015 Feb 15
0
[PATCH V5] x86 spinlock: Fix memory corruption on completing completions
...gt; static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) > { > - set_bit(0, (volatile unsigned long *)&lock->tickets.tail); > + set_bit(0, (volatile unsigned long *)&lock->tickets.head); > + barrier(); > } Because this barrier() looks really confusing. Firsty, it is equally unneeded on x86. At the same time, it can not help. We need a memory barrier() between set_bit(SLOWPATH) and READ_ONCE(head) to avoid the race with spin_unlock(). So I think you should replace it with smp_mb__after_atomic() or remove it. Other than that I believe this version is...
2015 Feb 15
0
[PATCH V5] x86 spinlock: Fix memory corruption on completing completions
...gt; static inline void __ticket_enter_slowpath(arch_spinlock_t *lock) > { > - set_bit(0, (volatile unsigned long *)&lock->tickets.tail); > + set_bit(0, (volatile unsigned long *)&lock->tickets.head); > + barrier(); > } Because this barrier() looks really confusing. Firsty, it is equally unneeded on x86. At the same time, it can not help. We need a memory barrier() between set_bit(SLOWPATH) and READ_ONCE(head) to avoid the race with spin_unlock(). So I think you should replace it with smp_mb__after_atomic() or remove it. Other than that I believe this version is...
2015 Feb 15
7
[PATCH V5] x86 spinlock: Fix memory corruption on completing completions
Paravirt spinlock clears slowpath flag after doing unlock. As explained by Linus currently it does: prev = *lock; add_smp(&lock->tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); which is
2015 Feb 15
7
[PATCH V5] x86 spinlock: Fix memory corruption on completing completions
Paravirt spinlock clears slowpath flag after doing unlock. As explained by Linus currently it does: prev = *lock; add_smp(&lock->tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); which is