search for: eixisting

There are tooooooo(!) many changes, I don't who's going to review sooooo big patch. You definitely need to split it into several smaller patches. Also, I don't like the idea adding of one more class for NVPTX codegen. All your changes should be on top of the eixisting solution. ------------- Best regards, Alexey Bataev 13.03.2019 15:08, Doerfert, Johannes пишет: > Please consider reviewing the code for the proposed approach here: > https://reviews.llvm.org/D57460 > > Initial tests, e.g., on the nw (needleman-wunsch) benchmark in the > rodinia...

...patches for different components. 2. Even inside of those components this patch must be split into several small patches, it is very hard to review so big patches. > > Also, I don't like the idea adding of one more class for NVPTX > codegen. All your changes should be on top of the eixisting solution. > > > Could you please explain to me why? This will only make everything > more complicated and entangled. > Also, the new class is supposed to be "target agnostic" so a new > offloading target, e.g., AMD GPUs, could easily reuse > the new code while the old...

...h could be split into two, SPMD-mode and > state machine creation. I'll wait for feedback on the other patches > until I go ahead. > > >>>> Also, I don't like the idea adding of one more class for NVPTX >>> codegen. All your changes should be on top of the eixisting solution. >>> >>> >>> Could you please explain to me why? This will only make everything >>> more complicated and entangled. >>> Also, the new class is supposed to be "target agnostic" so a new >>> offloading target, e.g., AMD GPUs,...

...ich could be split into two, SPMD-mode and > state machine creation. I'll wait for feedback on the other patches > until I go ahead. > > >>>> Also, I don't like the idea adding of one more class for NVPTX >>> codegen. All your changes should be on top of the eixisting solution. >>> >>> >>> Could you please explain to me why? This will only make everything >>> more complicated and entangled. >>> Also, the new class is supposed to be "target agnostic" so a new >>> offloading target, e.g., AMD GPUs, co...

Where we are ------------ Currently, when we generate OpenMP target offloading code for GPUs, we use sufficient syntactic criteria to decide between two execution modes: 1) SPMD -- All target threads (in an OpenMP team) run all the code. 2) "Guarded" -- The master thread (of an OpenMP team) runs the user code. If an OpenMP distribute region is encountered,