similar to: [LLVMdev] Target intrinsics and translation

On Nov 14, 2011, at 3:01 PM, Dan Gohman wrote: > LLVM (via clang) currently translates target intrinsics to generic IR > whenever it can. For example, on x86 it translates _mm_loadu_pd to a > simple load instruction with an alignment of 1. The backend is then > responsible for translating the load back to the corresponding > machine instruction. > > The advantage of this is

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, 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

Hello, This email picks up the thread that to my knowledge was last discussed here: http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html In brief, infinite loops containing no side effects produce undefined behavior in C++ (and C in some cases), however in other languages, they have fully defined behavior. LLVM's optimizer currently assumes that infinite loops eventually terminate

On Mon, 01 Oct 2012 21:26:54 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > > > Sanjoy Das <sanjoy at playingwithpointers.com> writes: > > > >> In short, I propose a intrinsic based approach which hinges on the > >> concept of a "parallel map". The immediate

On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > Sure, if you're willing to sacrifice the possible simplification of all indirect calls in any function that has even one nobuiltin requirement. > I don't understand what you mean by this. > 1) annotate calls > Pro: you can inline calls without pessimizing the function you inline into > Con:

On Mon, 01 Oct 2012 22:56:50 -0700 Chris Lattner <clattner at apple.com> wrote: > > On Oct 1, 2012, at 10:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Mon, 01 Oct 2012 21:26:54 -0700 > > Chris Lattner <clattner at apple.com> wrote: > > > >> > >> On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: > >>

On Oct 1, 2012, at 10:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Mon, 01 Oct 2012 21:26:54 -0700 > Chris Lattner <clattner at apple.com> wrote: > >> >> On Oct 1, 2012, at 6:16 PM, greened at obbligato.org wrote: >> >>> Sanjoy Das <sanjoy at playingwithpointers.com> writes: >>> >>>> In short, I propose a

Chris, > My comment was mostly in response to the Intel proposal, which effectively translates OpenMP pragmas directly into llvm intrinsics + metadata. I can't imagine a way to make this work *correctly* without massive changes to the optimizer. There are three ways to make this work correctly: 1) Ignore OpenMP-related intrinsics and associated metadata. Least effort, least benefit (no

Hi, Le 02/10/2012 19:29, Hal Finkel a écrit : > On Mon, 01 Oct 2012 22:56:50 -0700 > Chris Lattner <clattner at apple.com> wrote: >> On Oct 1, 2012, at 10:37 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On Mon, 01 Oct 2012 21:26:54 -0700 >>> Chris Lattner <clattner at apple.com> wrote: >>>> On Oct 1, 2012, at 6:16 PM, greened at

On Oct 2, 2012, at 3:09 AM, Andrey Bokhanko <andreybokhanko at gmail.com> wrote: > Chris, > >> My comment was mostly in response to the Intel proposal, which effectively translates OpenMP pragmas directly into llvm intrinsics + metadata. I can't imagine a way to make this work *correctly* without massive changes to the optimizer. > > There are three ways to make this

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

I'm working on intrinsics for my backend and require intrinsic overloading. Is this supported? If so, are there any examples? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100629/04db85ea/attachment.html>

On Wed, Feb 20, 2013 at 12:39 PM, Chris Lattner <clattner at apple.com> wrote: > On Feb 20, 2013, at 8:40 AM, David Blaikie <dblaikie at gmail.com> wrote: > > Sure, if you're willing to sacrifice the possible simplification of all > indirect calls in any function that has even one nobuiltin requirement. > > I don't understand what you mean by this. > 1)

On Oct 5, 2012, at 1:47 PM, Hal Finkel <hfinkel at anl.gov> wrote: > I don't really understand where you want to draw the line. Should the inliner get target-specific input? Inlining always does a canonical transformation. It can take whatever target data is available at it's level for heuristics, but that doesn't make it a target lowering pass. Similarly, full unrolling is

Each of the main TableGen files for the supported targets includes include "llvm/Target/Target.td" In turn, Target.td includes include "llvm/IR/Intrinsics.td" The final lines of Instrinsics.td are include "llvm/IR/IntrinsicsPowerPC.td" include "llvm/IR/IntrinsicsX86.td" include "llvm/IR/IntrinsicsARM.td" include

On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote: > It looks a little silly to say this in the case of the integer constant 5, > and there are some semantic gray areas around extra-VM allocation, but the > same thing happens if the add were adding a dynamic integer value, and then > it's difficult to find a way to separate that case from the constant

On Tue, Jun 29, 2010 at 12:16 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I'm working on intrinsics for my backend and require intrinsic overloading. > Is this supported? If so, are there any examples? Some of the ARM NEON intrinsics are overloaded. -Eli

Bill, Ben, everyone, Some time ago "target-features" and "target-cpu" attributes were introduced. As I understand, they are intended to support generation of "fat binaries" (binaries with functions generated for different CPUs), particularly to support LTO compilation, when different source files have different targets (say, one of files should support SSE2, another

Sanjoy Das <sanjoy at playingwithpointers.com> writes: > In short, I propose a intrinsic based approach which hinges on the > concept of a "parallel map". The immediate effect of using intrinsics > is that we no longer have to worry about missing metadata. Moreover, > we are still free to lower the intrinsics in a variety of ways -- > including vectorizing them or