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

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

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

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

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

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

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

Personally, I don't like the side effect intrinsic. It will pollute all the IR generated by non-C frontends. What most of these frontends really want is just a switch to disable a targeted set of optimizations. One thing I like about the function attribute idea is that it's conservatively correct to discard it when doing cross-language inlining. It just becomes something that C-family

There are a few places in llvm's generic codegen that refer to target specific intrinsics. This is bad layering and we shouldn't do it. It also means that if we don't build a target we still have to support all of it's intrinsics and other such annoyances. The main violator of this is InstCombineCalls - I'd like to push this into the targets, and just have a case that says

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, Could you please have a look at bug #16941 and let us know what you think about it? It's performance regression after one of your commits. Thanks. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/036e81d6/attachment.html>

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 Sep 15, 2014, at 4:17 PM, Owen Anderson <resistor at mac.com> wrote: > I’d be fine with that proposal. I could even be convinced if we wanted to add a pair of NaN-propagating intrinsics as well, for targets and languages that want those semantics, even if I disagree with them. I do think that, if we are using the minnum/maxnum names, we should explicitly note that they are

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

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