Size of kmp_task_t

Runtimes OpenMP
1

Hello.

I’m doing some experiments with the RTL and I’m seeing something that I could not understand. When I compile this code with clang (clang -S emit-llvm test.c -fopenmp):

//=--------------------------------------------------=//

#pragma omp parallel

{
#pragma omp task
fun();
}
//=--------------------------------------------------=//

the LLVM IR produced contains the following call to “task_alloc”, which, in this case, returns a structure with five fields:

//=--------------------------------------------------=//

%.task_t.val.addr = call { i8*, i32 (i32, i8*), i32, i32 (i32, i8), i32 } @__kmpc_omp_task_alloc({ i32, i32, i32, i32, i8* }* %.__kmpc_ident_t.2., i32 %.gtid., i32 %.flags., i64 ptrtoint ({ i8*, i32 (i32, i8*), i32, i32 (i32, i8), i32 } getelementptr ({ i8*, i32 (i32, i8*), i32, i32 (i32, i8), i32 } null, i32 1) to i64), i64 0, i32 (i32, i8*)* @.omp_ptask.)

//=--------------------------------------------------=//

the point is, when I inspect the RTL source code the structure kmp_task_t contains only four fields:

//=--------------------------------------------------=//

typedef struct kmp_task { /* GEH: Shouldn’t this be aligned somehow? */
void * shareds; /< pointer to block of pointers to shared vars */
kmp_routine_entry_t routine; /< pointer to routine to call for executing task */
kmp_int32 part_id; /**< part id for the task /
#if OMP_40_ENABLED
kmp_routine_entry_t destructors; / pointer to function to invoke deconstructors of firstprivate C++ objects /
#endif // OMP_40_ENABLED
/ private vars */
} kmp_task_t;

//=--------------------------------------------------=//

What am I doing wrong here? Am I using the wrong version of some library? To install the RTL and LLVM I followed the steps from: http://openmp.llvm.org/ and http://clang-omp.github.io/

2

Actually kmp_task_t can have more than 4 fields. See /* private vars */ comment. It is a place for a list of private variables used inside of task construct.

Best regards,
Alexey Bataev

3

I see; I had understood this comment as saying the allocation order of kmp_task_t and the private vars in memory (i.e., that private vars would be always allocated just after kmp_task_t) not really referring that kmp_task_t would be “re-shaped” by the compiler.

In the code example I sent before the “task function fun”, as I understand, does not have any private/shared vars. Why the structure still has a fifth field? Could you please point me to the LLVM code that compute that? Moreover, accessing these private vars through a pointer to an array, like what is done for shared vars, would make sense?

4

In clang-omp we have to create some additional fields for proper codegen. They are not used by runtime, but used by the codegen process. In official trunk implementation there won't be any of such junk fields.

Best regards,
Alexey Bataev