similar to: [LLVMdev] Publication: ispc compiler paper

Today Intel launched ispc, the Intel SPMD Program Compiler, an open-source compiler built on top of LLVM. It is available in both source and binary form from http://ispc.github.com/, under a BSD license. The goal of ispc is to provide a high-performance implementation of a C-based SPMD language for CPUs. The SPMD model has of course been quite successful for high-performance programming of

In the course of implementing the instruction scheduler for the Intel Atom in LLVM, I have run across a problem with the critical anti-dependence breaker, whereby CriticalAntiDepBreak.cpp code changes some XMM0 references to be XMM9 references. This would be all well and good, were it not for the fact that the result of the expression needs to be in XMM0 because it is being returned as the

I agree that a single vector index is sufficient for many cases. Matt Pharr (from the ISPC compiler), showed me an interesting case where there is a single pointer into an array. In this case we need to have two indices, where the first index is zero. Once the basic patch is in, we can start looking at adding support for arrays and multiple indices. Nadav -----Original Message----- From: David

On Jul 31, 2011, at 10:49 PM, Matt Pharr wrote: > I'm seeing some undesirable behavior where, when generating debugging information, sometimes the point in the debugger will jump forwards and backwards during single stepping, even though the output from our frontend (this is the ispc compiler), is emitting LLVM instructions with a strictly forward-moving/increasing set of source locations.

Duncan, Thanks for the quick review! Here is a short description (design) of where I am going with this patch: 1. Motivation: Vectors-of-pointers is the first step in supporting scatter/gather instructions (available in AVX2, for example). I believe that this feature was requested on the mailing list before. As mentioned by Hal Finkel earlier today, this feature is desired by autovectorizers as

Filed as http://llvm.org/bugs/show_bug.cgi?id=12678. On Apr 23, 2012, at 2:03 PM, llvmdev-request at cs.uiuc.edu wrote: > I'm seeing some strange behavior with generating debugging information from a simple program. (LLVM top of tree, minus a couple of days.) > > I suspect that there is a bug in LLVM, but thought I'd check in here to see if perhaps I'm doing something

We are working on OpenMP target offloading for GPUs in Flang, and adopting the same code generation strategy. The proposal is affecting us. It would be nice to know more details about the proposal. So we can prepare ourselves to adapt flang (if everything goes on the way). Have you find and a solution for data sharing? How are you going to manage data sharing for SPMD and non-SPMD? From: cfe-dev

I'm seeing some undesirable behavior where, when generating debugging information, sometimes the point in the debugger will jump forwards and backwards during single stepping, even though the output from our frontend (this is the ispc compiler), is emitting LLVM instructions with a strictly forward-moving/increasing set of source locations. I'm wondering if we're doing something wrong

Hi Nadav, ISPC is generating long vectors (on corresponding ISPC targets) this way since the every beginning of ISPC as far as I know. There's no such things in official LLVM documents as "illegal vectors", so people do expect that arbitrary long vectors are supported and generated reasonably well. Note, not super-optimal, but reasonably well. Keeping it this way allows considering

Hi Dmitry, ISPC does some instruction selection as part of vectorization (on ASTs!) by placing intrinsics for specific operations. The SEXT to i32 pattern was implemented because LLVM did not support vector-selects when this code was written. Can you submit a small SSE4 test case that demonstrates the problem? Select is the canonical form of this operations, and SEXT is usually more

Nadav, You are right, ISPC may issue intrinsics as a result of AST selection. Though I believe that we should stick to LLVM IR whenever is possible. Intrinsics may appear to be boundaries for optimizations (on both data and control flow) and are generally not optimizable. LLVM may improve over time from performance stand point and we would benefit from it (or it may play against us, like in this

Hi Dmitry. This looks like an ISPC workload. ISPC works around a limitation in selection dag which does not know how to legalize mask types when both 128 and 256 bit registers are available. ISPC works around this problem by expanding the mask to i32s and using intrinsics. Can you please verify that this regression only happens on AVX ? Can you change ISPC to use intrinsics ? Thanks Nadav Sent

Nadav, You are absolutely right, it's ISPC workload. I've checked SSE4 and it's also severely affected. We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on

Hi Dmitry, Yes, this is a known problem with legalizing vector masks. The type <8 x i1> is legalized to 8 x i16, on SSE, but your operands are legalized to <4 x i32>. Type-legalization is performed per-node and we don’t have a good way to support instructions that mix the mask and operand type. Why does ISPC generate illegal vector types ? Does ISPC rely on the LLVM codegen to

We could still do that in clang, couldn't we? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Alexey Bataev <a.bataev at outlook.com> Sent: Tuesday, January 22, 2019 12:52:42 PM To: Doerfert, Johannes Rudolf; cfe-dev at lists.llvm.org Cc: openmp-dev at lists.llvm.org; LLVM-Dev; Finkel, Hal J.; Alexey Bataev; Arpith Chacko Jacob Subject: Re:

Could you elaborate on what you refer to wrt data sharing. What do we currently do in the clang code generation that we could not effectively implement in the runtime, potentially with support of an llvm pass. Thanks, James Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Alexey Bataev <a.bataev at outlook.com> Sent: Tuesday, January 22, 2019

On Apr 24, 2012, at 5:36 AM, Renato Golin wrote: > On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: >> When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped

Has anyone worked with or used the LLVM backend or compiler for Haskell ?? David On Monday, October 21, 2013 5:26 PM, "llvmdev-request at cs.uiuc.edu" <llvmdev-request at cs.uiuc.edu> wrote: Send LLVMdev mailing list submissions to     llvmdev at cs.uiuc.edu To subscribe or unsubscribe via the World Wide Web, visit     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev or,

On my Centos 7 update, into "journalctl -f" I have tons of this kind of message > feb 17 23:52:09 s-ispc.local systemd-logind[663]: Got message type=signal sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/unit/php_2dfpm_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=17152 reply_cookie=0 error=n/a > feb 17 23:52:09 s-ispc.local

We would still know that. We can do exactly the same reasoning as we do now. I think the important question is, how different is the code generated for either mode and can we hide (most of) the differences in the runtime. If I understand you correctly, you say the data sharing code looks very different and the differences cannot be hidden, correct? It would be helpful for me to understand your