similar to: Legal names for Functions and other Identifiers

Thank You Chen ! On Thu, Jun 22, 2017 at 5:21 PM 陳韋任 <chenwj.cs97g at g2.nctu.edu.tw> wrote: > Perhaps you can refer to [1]. Function name should be a global one. > > [1] http://llvm.org/docs/LangRef.html#identifiers > > HTH, > chenwj > > > 2017-06-22 16:35 GMT+08:00 SANJAY SRIVALLABH SINGAPURAM via llvm-dev < > llvm-dev at lists.llvm.org>: > >>

Hello, Can anyone help me with the default installation locations of CUDA headers in Windows and macOS ? e.g. /usr/local/cuda/include is the default for Linux. Thanks, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170522/ca97c66b/attachment.html>

Hello, My system hangs every time during last stages of building LLVM ( starting at 95% in a CMake build ) using CMake or Ninja, sometime close to the linking of llvm-dysmutil. Could you please suggest tips that could speed up the compilation ? Thank You, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello ! Does the x86 back-end generate gather-scatter instructions for LLVM gather-scatter intrinsics ? Also, do the NVPTX and AMDGPU back-ends generate equivalent instructions for GPUs ? Thank You, Sanjay -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170220/dc51b7cd/attachment.html>

Thanks for the heads up Philip ! I did come across a strange case where LLVM allowed "%" to be a part of a function's name. This was in the context of my patch https://reviews.llvm.org/D33985, where I prefix the name of the source function and the Scop ( A special kind of Region that Polly can optimize, the name of the Scop is the name of the Region ) to the name of the PTX kernel

Hello, I issued the following command to point the build to use clang and clang++, from a local llvm build directory included in PATH, instead of /usr/bin/{cc,c++}, cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm_src The configuration failed with the error stating the compiler didn't recognize '-std=c++11' flag, whereas clang compiled a dummy c++ file with

Hello, I'm working on a project involving LLVM and keep shifting between the Debug and Release build by assigning different values to CMAKE_BUILD_TYPE in <llvm_build>/CMakeCache.txt and then building it. I wanted to know if this was a safe alternative to re-configuring the build after removing <llvm_build>/CMakeFiles/ and <llvm_build>/CMakeCache.txt. Thanks, Sanjay

Do the InitializeAllTargets*() routines call the initialisation routines of all targets even when only some are built ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170323/08bd52a0/attachment.html>

Hello, One of my Julia programs failed to execute with the following error, DICompileUnit not listed in llvm.dbg.cu !11 = distinct !DICompileUnit(language: DW_LANG_C89, file: !3, producer: "julia", isOptimized: true, runtimeVersion: 0,emissionKind: FullDebug, enums : !12) This was generated by verifyModule(*GPUModule,&(llvm::errs())From whithin PPCGCodeGeneration.cpp in Polly.

On Sat, Mar 11, 2017, at 07:34 PM, David Blaikie via llvm-dev wrote: > On Sat, Mar 11, 2017 at 3:10 AM SANJAY SRIVALLABH SINGAPURAM via llvm-dev > < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > One of my Julia programs failed to execute with the following error, > > DICompileUnit not listed in llvm.dbg.cu > > !11 = distinct

Hal, Tobias, et al. – I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far our best bet to make that happen. I have a couple of questions: 1) Integer constraint libraries like ISL (and Omega, which I used extensively in a previous project) are fundamentally solving

On Mon, Sep 4, 2017, at 20:49, Hal Finkel via llvm-dev wrote: > [tying to original thread] > > On 09/04/2017 01:37 PM, Adve, Vikram Sadanand via llvm-dev wrote: > > Hal, Tobias, et al. – > > > > I am strongly in favor of seeing a broader range of loop transformations, supported by strong dependence analysis, added to LLVM, and the Polly infrastructure seems to be by far

Machine is running x86 snv_94 after recent upgrade from opensolaris 2008.05. ZFS and zpool reported no troubles except suggesting upgrade for from ver.10 to ver.11. seemed like a good idea at the time. system up for several days after that point then took down for some unrelated maintenance. now will not boot the opensol, drops to grub prompt, no menus. zfs was mirrored on two disks c6d0s0 and

** *Hi everyone,As you may know, stock LLVM does not provide the kind of advanced loop transformations necessary to provide good performance on many applications. LLVM's Polly project provides many of the required capabilities, including loop transformations such as fission, fusion, skewing, blocking/tiling, and interchange, all powered by state-of-the-art dependence analysis. Polly also

A completely non-technical point, but what's the current "polly" license? Does integrating that code conflict in any way with the work being done to relicense llvm? Does adding polly expose any additional legal risks? Some people from Reservoir labs have explicitly stated to me that some of their patents target polyhedral optimizations. You should almost certainly review their

On 09/11/2017 12:26 PM, Adam Nemet wrote: > Hi Hal, Tobias, Michael and others, > >> On Sep 1, 2017, at 11:47 AM, Hal Finkel via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> ** >> >> *Hi everyone,As you may know, stock LLVM does not provide the kind of >> advanced loop transformations

Amara, >I support this direction Thanks for the support. >but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in some form.’ It's not like I have specific application code in

On 01/05/2018 06:28 PM, Saito, Hideki wrote: > Amara, > >> I support this direction > Thanks for the support. > >> but are there actually any real world workloads where gather/scatter scalarisation would be worth it, on any micro-architecture? If we don’t have examples and the compile time cost is non-negligible then I think we’d still like to keep the early >bailouts in

Thanks, Hal. I plan to post a patch w/o HW Legality early bailout first. That should enable further discussion on where the initial very high cost for "illegal masked load/store/gather/scatter" should be coming from --- like should LoopVectorize provide it? Or should it be provided by TTI? I prefer the latter (TTI) but the first revision of the patch will intentionally do the former

> On Sep 11, 2017, at 10:47 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 09/11/2017 12:26 PM, Adam Nemet wrote: >> Hi Hal, Tobias, Michael and others, >> >>> On Sep 1, 2017, at 11:47 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>>