search for: omp_data_s

Dear All, I am trying to understand the process followed for converting GIMPLE IR to LLVM IR in LLVM-GCC/DragonEgg - more importantly conversion of OpenMP extended GIMPLE IR to LLVM IR. It would be great if anybody points me to some documentation before I my-self delve into the understanding of related source code. -- Cheers -mahesha -------------- next part -------------- An HTML attachment

...4:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" >> target triple = "x86_64-unknown-linux-gnu" >> >> module asm "\09.ident\09\22GCC: (GNU) 4.7.1 20120603 (prerelease) LLVM: >> 3.2svn\22" >> >> %struct..omp_data_s.2 = type { i32* } >> %struct..omp_data_s.1 = type { i32* } >> %struct..omp_data_s.0 = type { i32 } >> >> define internal void @foo._omp_fn.2(i8* nocapture %.omp_data_i) nounwind >> uwtable { >> entry: >> %0 = bitcast i8* %.omp_data_i to i32** >>...

.... Example program from Diego's paper now compiles to: @.str = internal constant [10 x i8] c"sum = %d\0A\00" ; <[10 x i8]*> [#uses=1] define i32 @main() { entry: %sum = alloca i32 ; <i32*> [#uses=3] %.omp_data_o.3 = alloca %struct..omp_data_s.1 ; <% struct..omp_data_s.1*> [#uses=2] store i32 0, i32* %sum, align 4 %tmp = getelementptr %struct..omp_data_s.1* %.omp_data_o.3, i32 0, i32 0 ; <i32**> [#uses=1] store i32* %sum, i32** %tmp, align 8 %.omp_data_o.31 = bitcast %s...

...tly, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence establishing a connection to the debug metadata does not seem possible. In the other case, I am noticing some extra fields present in the `omp_data_s' structure (these fields are not present in the source code) and hence the `alloca' does not match the metadata definition. Here are the details: http://users.ices.utexas.edu/~ashay/tmp/llvm.html Does lldb have similar goals? If yes, which files should I be looking at? Any pointers are a...

...tly, the original variable name is no longer present in the bitcode). The other two problems concern OpenMP. In one case, the instruction is not named and hence establishing a connection to the debug metadata does not seem possible. In the other case, I am noticing some extra fields present in the `omp_data_s' structure (these fields are not present in the source code) and hence the `alloca' does not match the metadata definition. You may try clang. It generates the debugging information you want. - xi

...riable name is no > longer present in the bitcode). The other two problems concern OpenMP. In > one case, the instruction is not named and hence establishing a connection > to the debug metadata does not seem possible. In the other case, I am > noticing some extra fields present in the `omp_data_s' structure (these > fields are not present in the source code) and hence the `alloca' does not > match the metadata definition. > > You may try clang. It generates the debugging information you want. > > - xi > > -------------- next part -------------- An HTML attac...

...55617, metadata !52, metadata !".omp_data_i", metadata !1, i32 316, metadata !237, i32 0, i32 0} !237 = metadata !{i32 655375, metadata !1, metadata !"", metadata !1, i32 0, i64 64, i64 64, i64 0, i32 64, metadata !238} !238 = metadata !{i32 655379, metadata !1, metadata !".omp_data_s.18", metadata !1, i32 0, i64 320, i64 64, i64 0, i32 0, null, metadata !239, i32 0, null} !239 = metadata !{metadata !240, metadata !241, metadata !242, metadata !243, metadata !244, metadata !245} !240 = metadata !{i32 655373, metadata !238, metadata !"ly", metadata !1, i32 306, i64...