similar to: [LLVMdev] Question on Fence Instruction

Thank you very much for the quick reply. I was trying to confirm what I did was correct. I did a test that could enable a simple way of sc-preserving compilation by inserting fences for every load/store instruction before any opts, applying standard opts and then removing them after assembly code generation. It turned out that such sc-preserving compilation only caused ~4% slowdown for 18

On 10/17/12 9:21 AM, Duan, Yue Lu wrote: > Thank you very much for the quick reply. I was trying to confirm what I did was correct. I did a test that could enable a simple way of sc-preserving compilation by inserting fences for every load/store instruction before any opts, applying standard opts and then removing them after assembly code generation. It turned out that such sc-preserving

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

Hi, The paper is "A Case for an SC-Preserving Compiler" from PLDI 2011. What I did is following their "naive SC preserving compilation", that restricts the compiler to do any reordering for potentially shared load/store instructions. The paper says the resulting code running on x86 machine (SC-preserving binary run on non-SC hardware) will get 22% slowdown comparing with a

Hi, I recently looked into the LICM(Loop Invariant Code Motion) pass of LLVM and got a question about hoist load instruction to loop preheader. I would like to show two examples: Example 1: int func(int n, int *fp) { int i; int a[1000]; for (i = 0; i < n; ++i) { a[i] += *fp; // load from *fp pointer, no hoist } } Here, load *fp CAN NOT be hoisted to loop preheader. If replace *fp

Hi all, I think it's Gentoo's bug, but I want to know if anyone has the same issue here. I am compiling LLVM trunk on Gentoo (gcc 4.5.2), and I get error message below, --- make[4]: Entering directory `/nfs_home/chenwj/llvm-3.1/svn/build/tools/clang/lib/Frontend' llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build

Hi Justin, I believe the PTX section in the link below need some love, updating "lib/Target/PTX" to "lib/Target/NVPTX" for example. Would you like to take a look? http://llvm.org/docs/CodeGenerator.html#the-ptx-backend Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Hi all when i compiled llvm-3.0 with icedtea1.11.4 together,A memory_barrier error happened ,And now I write to all of you for the following questions need your help and suggestion : 1, Is any function which can replace the "make_function" in the following function, 2 , Or is there any different paramters in make_function with the similar action with the following one

> In consideration of those codes in XXXAsmPrinter class which print out > MachineInstr in .s format, I tend to think they are old codes that > might be obsolete and will be replaced with MC layer implementation, > but I am not sure. How about sending a patch which remove those obsolete code, and let others give comment? Cheers, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab,

Hi Pawel, PTX already be replaced with NVPTX. However, PTX subdirectory still sit in lib/Target in 3.2 release. Do you think update the release tarball is a good idea? Also could you remove it from the trunk? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage:

Hi all, While building/testing LLVM/Clang on ARM, I often have problems that are undocumented on the website. I would like to contribute my experience if possible so that others can benefit from it. If this is a good idea, I am wondering on what page I should write it down, [1] or [2]? Regards, chenwj [1] http://llvm.org/docs/GettingStarted.html [2] http://llvm.org/docs/FAQ.html -- Wei-Ren

On Mon, Nov 07, 2011 at 04:10:29PM +0100, Wim Vander Schelden wrote: > I'm having the same problem. Does anyone know what's causing this? > > Kind regards, > > Wim What's your profiling procedure? I can only guess llvm-prof does not recognize the profiling data. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia

> still a question: > what does "; PR1028" means? I believe it means this test case addresses bug report (pr, problem report) 1028 [1]. In other words, this test case guarantee that pr1028 will not back again. If so, it will fail. Regards, chenwj [1] http://llvm.org/bugs/show_bug.cgi?id=1028 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science,

Thx all for the quick answers... > De : llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] de la part de Arnaud ALLARD DE GRANDMAISON [arnaud.allarddegrandmaison at parrot.com] > > Hi, > > Depending on what have run before your pass, the loop may have been unrolled or simplified if the computation inside the loop is too simple. > > Cheers, > -- > Arnaud de

Hi all, I have some troubles in writing XXInstFormat.td for my little backend. I don't know how should I start writing up this file. Is there any general rule? Thanks. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj

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 var pointer, it returns true. As a result no hoist > happens for a load *fp: the function

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 >>

Hi, When I tried to use the latest version of LLVM tools (clang as the frontend) to compile and link a project with multiple c files, it appears that each of the generated .bc file contains a definition of pthread_equal, resulting llvm-link failure with error message "multiply symbols defined". I tried but did not get any answer on the web. So I turn to you for help. Here is the

Hi 陳韋任, Sorry for the late response. On Apr 21, 2012, at 8:03 PM, 陳韋任 wrote: > I have a native compile and the result seems better... You can compare > the result of cross compile [1] and the native compile [2]. > > Any though? > I'm not particularly happy about the failures here. We need to get to the bottom of them. In the previous email, you tried setting CFLAGS and

Hello all, I caught a problem related to pthread library. I built llvm and llvm-gcc then compiling a multithreaded benchmark written in POSIX thread library. The command "llvm-gcc -o bench bench.c -lpthread" ran well while "llvm-gcc -c bench; llvm-ld -o bench bench.o -lpthread" crashed. It told that "llvm-ld: error: Cannot find library 'pthread'". I could