similar to: [LLVM][RFC] Representing the target device information in the LLVM IR

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

Given a global variable @gg, the compiler has to generate code on the host to specify whether it is passed by value or passed by reference. In the following example, if the compiler generates the code for passing by value, the outlined function on the target i386-pc-linux-gnu cannot get the correct value since it assumes the variable @gg is passed by reference. Here is the corresponding IR on the

For the firstprivate clause, the compiler generates code to pass it by value or by reference to the outlined function. The reason the first private scalars is generally passed by value is for the performance reason. For this particular case, the compiler cannot generate code to pass the double @gg by value under i386-pc-linux-gnu since the value is 64 bit while the architecture is 32bit. For the

Hi, Jin, Can you please back up a bit and talk about the programming environment in which this problem manifests? If I have a host and a target with different ABIs, then it seems we have lots of problems. For one thing, the layouts of structures are different, the sizes of some integer types are different, the sizes of pointers are different, and so on. It seems like a solution in this space

On 04/26/2018 07:03 PM, Narayanaswamy, Ravi wrote: > > Hi Hal, > >    We are not trying to address issues where the object mapped are of > different sizes between host and target with different ABI. > Why are you not trying to address that issue?  -Hal > The issue is when the objects are of same size like double which is > 8bytes on both 32bit and 64bit platform.  If a

On 4/25/2018 3:48 PM, Lin, Jin wrote: > > Given a global variable @gg, the compiler has to generate code on the > host to specify whether it is passed by value or passed by reference. > In the following example, if the compiler generates the code for > passing by value, the outlined function on the target > i386-pc-linux-gnucannot get the correct value since it assumes the

Hi Hal, We are not trying to address issues where the object mapped are of different sizes between host and target with different ABI. The issue is when the objects are of same size like double which is 8bytes on both 32bit and 64bit platform. If a double is used in a first_private on a target clause, the 64 bit side will pass it as value whereas on the 32bit side since the value does not

And “map” and “firstprivate” … are represented as MDString, right? Thanks. From: Hongbin Zheng [mailto:etherzhhb at gmail.com] Sent: Wednesday, January 11, 2017 3:58 PM To: Tian, Xinmin <xinmin.tian at intel.com> Cc: David Majnemer <david.majnemer at gmail.com>; Hal Finkel <hfinkel at anl.gov>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [RFC] IR-level Region

Interesting, this is similar to what we have. One more question, these stuff in the yellow, are they represented as LLVM VALUEs? In other words, does the LLVM optimizer update them? ,E.g. %m is re-named %m.1 in the loop, is the “m” in the token @..... is updated as well? In the RFC, the “m” is argument of intrinsic call, all use-def info are used by optimizer, and optimizer updates them

Hello, I am getting the following error while trying to build a benchmark with a custom function pass: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c error: unknown argument: '-fopenmp=libomp' If I use this instead: clang -Xclang -fopenmp=libomp -Xclang -load -Xclang my_lib.so file.c I get the error: fatal error: 'omp.h' file not found I am not

Hal, Andrey, Alexey, >From the LLVM design viewpoint, there is a fundamental problem with both Hal's approach and the Intel approach: both are quite language-specific. OpenMP is a particular parallel language, with particular constructs (e.g., parallel regions) and semantics. LLVM is a language-neutral IR and infrastructure and OpenMP-specific concepts should not creep into it. I've

On Sat, May 02, 2015 at 11:18:35PM +0300, Andrey Bokhanko wrote: > 3) Some people believe that libiomp is not a proper name anymore and > should be changed. I'm not a library expert, so really don't know. > However, this means that we should flip default library setting ASAP. > Why? Because now "libiomp5" is a user-visible name (one has to use >

Jack, Alexey [Bataev] promised to send it for review in a day or two. Then it should be approved by code reviewers, which might take some time. andrey Отправлено с iPad > 12 мая 2015 г., в 21:22, Jack Howarth <howarth.mailing.lists at gmail.com> написал(а): > > Andrey, > Any idea when the patch to enable openmp as the default for > -fopenmp will be posted to

No, just changing defaults -- subject to code reviewers approval. As I said before, I prefer to leave library naming to library pros. Andrey On Fri, May 8, 2015 at 7:21 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > So you plan on switching and enabling the openmp library defaults as > well as changing the openmp library name at the same time? > Jack >

Jack, Could you, please, submit a bug report? -- including steps to reproduce (where you got imageMagick sources, how exactly you compiled them, etc) Andrey On Fri, May 1, 2015 at 3:56 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > > On Fri, May 1, 2015 at 4:45 AM, Andrey Bokhanko <andreybokhanko at gmail.com> > wrote: >> >> Chandler,

Jack, this is not a problem of this patch, this a problem of your configuration. This patch uses standard clang machinery for locating libiomp5 library. Best regards, Alexey Bataev ============= Software Engineer Intel Compiler Team 13.05.2015 15:59, Jack Howarth пишет: > On Tue, May 12, 2015 at 3:58 PM, <andreybokhanko at gmail.com> wrote: >> Jack, >> >> Alexey

Hi, <This issue was previously posted in R-help, but advised to post here as a more relevant group> I was trying to install RQuantLib in my Ubuntu machine which failed with below information : *> install.packages('RQuantLib', repos='http://cran.rstudio.com/ <http://cran.rstudio.com/>', INSTALL_opts = c('--no-lock'))* *Installing package into

On Thu, May 7, 2015 at 10:53 PM, Hans Wennborg <hans at chromium.org> wrote: > Congratulations! Would you like to add a blurb to the release notes > for the next release? Sure! Will do. Yours, Andrey

Hi Jack, On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > Hans, > Do we intend to leave -fopenmp defaulted to the no-op libgomp > support for 3.7.0 or do the sensible thing by applying... > > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 242425)

Hi all, I'm trying to get the llvm's IR from the source code of Polybench (OMP) https://github.com/cavazos-lab/PolyBench-ACC/tree/master/OpenMP. I noticed a considerable difference between the IR generated using clang -emit-llvm -fopenmp and clang -emit-llvm: * using the -fopenmp flag I get a simplified IR in which I read a single basic block where I can highlight a llvm.memcpy