similar to: [LLVMdev] "target-features" and "target-cpu" attributes

On Oct 3, 2013, at 9:34 AM, Dmitry Babokin <babokin at gmail.com> wrote: > 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

Bill, Thanks for answering. To make sure that we are on the same page, let's agree on definitions :) Here, by fat binaries I mean the binary, where some functions are compiled for one flavor of x86, while others are compiled for another flavor of x86. I care about the usage model, which is important for LTO - a dispatch function (compiled for the least common denominator) + plus set of

Bill, Are there any chances that you complete it before 3.4 is branched? On Thu, Oct 10, 2013 at 10:16 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Oct 10, 2013, at 4:22 AM, Dmitry Babokin <babokin at gmail.com> wrote: > > > Bill, > > > > Thanks for answering. To make sure that we are on the same page, let's > agree on definitions :) Here, by

Looking forward to these changes! Thanks for working on it. On Fri, Oct 11, 2013 at 10:32 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Dmitry, > > I can try my best, but it would be a bit tricky to get it all finished by > then... > > -bw > > On Oct 11, 2013, at 4:10 AM, Dmitry Babokin <babokin at gmail.com> wrote: > > Bill, > > Are there

Hi Dmitry, I can try my best, but it would be a bit tricky to get it all finished by then... -bw On Oct 11, 2013, at 4:10 AM, Dmitry Babokin <babokin at gmail.com> wrote: > Bill, > > Are there any chances that you complete it before 3.4 is branched? > > > On Thu, Oct 10, 2013 at 10:16 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Oct 10, 2013, at

FYI: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066389.html Please read and let me know you comments. -bw On Oct 11, 2013, at 2:47 PM, Dmitry Babokin <babokin at gmail.com> wrote: > Looking forward to these changes! Thanks for working on it. > > > On Fri, Oct 11, 2013 at 10:32 PM, Bill Wendling <isanbard at gmail.com> wrote: > Hi Dmitry, > > I

On Oct 10, 2013, at 4:22 AM, Dmitry Babokin <babokin at gmail.com> wrote: > Bill, > > Thanks for answering. To make sure that we are on the same page, let's agree on definitions :) Here, by fat binaries I mean the binary, where some functions are compiled for one flavor of x86, while others are compiled for another flavor of x86. I care about the usage model, which is

Nadav, The problem appears only for vectors longer than available hardware register (in doubleword elements, i.e. more than 4 on SSE4 and more than 8 on AVX). Select does weird thing. <8 x i1> mask comes as two XMM registers, select converts them to a single XMM registers (i.e. 8 x 16 bit), immediately after it converts back to two XMM registers and does blend. Conversion forth and back has

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

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

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

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

On Oct 21, 2013, at 12:09 PM, Dmitry Babokin <babokin at gmail.com> wrote: > By the way, I'm curious, is the any reason why you focus on SSE4, not AVX? Seems that vectorizer should care the most about the latest silicon. > I am interested in looking at the SSE4 code because lowering of AVX code is more complicated, especially for masks. The problem that <8 x i1> can be

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>

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

Hi Jake, many thanks, yea, I have very similar feelings / thoughts. After some thinking it seems to me that this discussion/problem which I have brought up is, in fact, more relevant to the tools which really need a robust mutable model of an object file (like objcopy, strip, install_name_tool, etc), but the particular case of "lipo" might be simpler, I need to double check that / will

Hey everyone! In October/November 2018 I started the implementation of llvm-objcopy for MachO with the long-term plan to build some popular binary-level tools on top of it. That effort stopped at the stage where some boilerplate code for reading/writing MachO files was reviewed & committed to LLVM/tools/llvm-objcopy. Later I started working on llvm-lipo (a drop-in replacing for the tool

Every case is different, but yes, as I said - I would like to take a closer look at the problem again, it might be the case that we don't need this complexity in this particular case, but want to double check. But yeah, in general I agree with you! On Thu, May 9, 2019 at 6:09 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > I think that pretty much hits the nail on the head.

Hey everyone! Objcopy is a powerful tool that allows one to modify object files in various manners, for example, modify symbols / symbol tables or copy / remove particular parts of a binary. It also serves as a basis for the strip tool. Currently, llvm-objcopy only supports ELF files while binutils' objcopy can handle Mach-O files as well. Besides extending the existing tool to support Mach-O