search for: __tgt_target

On 4/25/2018 3:05 PM, Lin, Jin via llvm-dev wrote: > > RFC: Representing the target device information in the LLVM IR > > =========================================================================== > > Why this RFC change? > > ================= > > The target device information needs to be passed to the LLVM backend > when OpenMP backend outlining is enabled. For

...rresponding IR on the host side. %0 = load double, double* @gg, align 8, !tbaa !3 %1 = bitcast double %0 to i64 ... %12 = getelementptr inbounds [4 x i8*], [4 x i8*]* %.offload_baseptrs, i32 0, i32 2 %13 = bitcast i8** %12 to i64* store i64 %1, i64* %13, align 8 ... %20 = call i32 @__tgt_target(i64 -1, i8* @.omp_offload.region_id, i32 4, i8** %4, i8** %6, i64* getelementptr inbounds ([4 x i64], [4 x i64]* @.offload_sizes, i32 0, i32 0), i64* getelementptr inbounds ([4 x i64], [4 x i64]* @.offload_maptypes, i32 0, i32 0)) Thanks, Jin From: Friedman, Eli [mailto:efriedma at codeaurora.or...

RFC: Representing the target device information in the LLVM IR =========================================================================== Why this RFC change? ================= The target device information needs to be passed to the LLVM backend when OpenMP backend outlining is enabled. For example, for multiple target devices, the target compilation has to generate a single host to support all

...there are pending tasks, and then call its synchronous versions. So, is it a good idea to wrap them in functions that call them as asynchronous (using std::async), then return an object to wait on?. Then, waiting on the object returned. 2. I'm thinking on replacing the data transfer inside __tgt_target_teams with __tgt_target_data_begin. The problem with this is that __tgt_target_data_begin does not initialize [first]private variables, and doesn't check for lambda mappings. Therefore, my idea to go around this problem is to create another wrapper function F, that calls __tgt_target_data_...

Hi Johannes, In order to create the testcases with the FIXMEs showing how it should look after the transformation, I've been trying to come up with a way of splitting the runtime call __tgt_target_teams based on Silei's recent patch D77005. I like the idea of using its asynchronous version __tgt_target_teams_nowait, but I think we would have to modify it, either to return the async_info struct: __tgt_async_info __tgt_target_teams_nowait(...) // This would break the current canonical...

Hi Johannes, Sorry about the failing tests. I completely forgot about running all of them, I only ran the tests for the openmp ipo transforms. I found the GH issue in cache. I can post it here if you want. I analyzed these runtime calls, __tgt_target_teams_[nowait]. What I don't understand about the problem we want to solve (splitting the memory transfer into issue and wait and legally moving code inside) is that the memory transfer is made inside those runtime calls. Therefore, the runtime calls to the memory transfer cannot be analyze...