search for: yuelu

...ecute() hoist(I); But I do not know why we need to treat fp/local pointer different with global pointer here. I think hoisting fp/local pointers should be fine if they are loop invariant and does not alias with other pointers.. Anyone can help me to figure this out? Thank you very much. -Yuelu, UIUC

...on average on a Intel Xeon machine. The result surprised me a lot because it was reported that such naive way of compilation can cause 20% slowdown in a recent PLDI paper (they also use LLVM), so I posted this question. I will try to examine if the generated binary code really respects sc fences. Yuelu ________________________________________ From: 陳韋任 (Wei-Ren Chen) [chenwj at iis.sinica.edu.tw] Sent: Wednesday, October 17, 2012 9:00 AM To: Duan, Yue Lu Cc: llvmdev at cs.illinois.edu Subject: Re: [LLVMdev] Question on Fence Instruction On Tue, Oct 16, 2012 at 01:44:57PM +0000, Duan, Yue Lu wrot...

...consistency. In other words, while you've ensured that the compiler doesn't do anything to violate sc, you're letting the hardware violate sc. Are you compiling for a machine that is sequentially consistent by default? Also, to what PLDI paper are you referring? -- John T. > > Yuelu > ________________________________________ > From: 陳韋任 (Wei-Ren Chen) [chenwj at iis.sinica.edu.tw] > Sent: Wednesday, October 17, 2012 9:00 AM > To: Duan, Yue Lu > Cc: llvmdev at cs.illinois.edu > Subject: Re: [LLVMdev] Question on Fence Instruction > > On Tue, Oct 16, 2012...

Hi Yuelu, > After tracking the LICM pass, I find that both loads are loop > invariant, and canSinkOrHoist() also returns true; however the > difference is at Instruction::isSafeToSpeculativelyExecute(), > for load from function parameter pointer, it return false; with load > from a global va...

On Tue, Feb 8, 2011 at 4:55 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Yuelu, > >> After tracking the LICM pass, I find that both loads are loop >> invariant, and canSinkOrHoist() also returns true; however the >> difference is at Instruction::isSafeToSpeculativelyExecute(), >> for load from function parameter pointer, it return false; with load &...

...q i32 %__thread1, %__thread2 %conv = zext i1 %cmp to i32 ret i32 %conv } That results multiple definitions of the same function and the linkage error. NOTE: The above compile and link method works for single C file program. So what do I miss that can avoid this issue? Thank you very much! Yuelu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120929/5d4faa13/attachment.html>

...ter every load/store instruction, before any opt is done, and then apply those standard compile transformations, would the result code be SC-preserving? In other words, does the compiler restrict any reordering for potentially shared accesses that "protected" by these fences? Thank you. Yuelu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121016/cf5e161f/attachment.html>

...iction in compilation only lead to 4% slowdown, way less than the paper's report. The reason could be that the compiler does not respect SC fences so unexpected reordering is done and lead to better performance. It could also be that their implementation is different than mine. I am not sure. -Yuelu ________________________________________ From: John Criswell [criswell at illinois.edu] Sent: Wednesday, October 17, 2012 9:45 AM To: Duan, Yue Lu Cc: "陳韋任 (Wei-Ren Chen)"; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Question on Fence Instruction On 10/17/12 9:21 AM, Duan, Yue Lu wrot...

On Tue, Oct 16, 2012 at 01:44:57PM +0000, Duan, Yue Lu wrote: > Hi, > > I have a question with the latest released LLVM which supports Fence > Instruction as IR. Say if I intentionally place a Sequentially Consistent Fence > Instruction somewhere in the code, then would the other transformation passes > that applied later respect the Fence and do not perform any reordering