similar to: [Proposal] Introducing the concept of invalid costs to the IR cost model

Hi Chris, Thanks for the reply. My email was really to just ask if people were ok with the idea in principle and I kind of deliberately avoided getting into too many details at this point. If people are happy with the idea in principle I can push a patch up soon that shows what such a class could like so that people can comment on it? Regards, David Sherwood. From: Chris Tetreault <ctetreau

You're being quite vague about what the extra state is. Is this because you haven't yet settled on what it should be, or do you actually intend to let it be a template parameter: template <typename T> struct Cost { unsigned Val; T State; } Thanks, Christopher Tetreault From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of David Sherwood via llvm-dev Sent:

Makes sense. I personally greatly prefer having a type rather than a `static constexpr int CostUnfathomable = 10000`. I think the type should have arithmetic operators defined such that an "invalid cost" on either side results in an invalid cost (similar to how NaN infects floats), and an implicit conversion that constructs a valid cost. Then I could just do: ``` Cost c = 7; // c is a

It might also make sense to have functions that return costs for vector ops return some sort of `LinearPolyBase` with `ScalarTy` being `InstructionCost`. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Vineet Kumar via llvm-dev Sent: Monday, November 16, 2020 11:24 PM To: David Sherwood <David.Sherwood at arm.com>; llvm-dev at lists.llvm.org Subject: [EXT] Re:

Hi, I'm looking for APIs that compute instruction costs, and noticed several of them. 1. A series of APIs of TargetTransformInfo that compute the cost of instructions of a particular type (e.g. getArithmeticInstrCost and getShuffleCost) 2. TargetTransformInfo::getOperationCost 3. CostModel::getInstructionCost::getInstructionCost in lib/Analysis/CostModel.cpp Only the first one is used

Nadav Rotem <nrotem at apple.com> writes: > On Nov 14, 2013, at 2:32 PM, Richard Sandiford > <rsandifo at linux.vnet.ibm.com> wrote: >> Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: >>> Are you worried that adding it to PMB will increase compile time? >>> The pass exits very early for any target that doesn't opt-in to doing

Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: > Are you worried that adding it to PMB will increase compile time? > The pass exits very early for any target that doesn't opt-in to doing > scalarisation at the IR level, without even looking at the function. As an alternative, adding Scalarizer and InstCombine passes to SystemZPassConfig::addIRPasses() would probably

Hi all, It's been a while since we've given an update on scalable vector support in LLVM. Over the last 12 months a lot of work has been done to make LLVM cope with scalable vectors. This effort is now starting to bear fruit with LLVM gaining more capabilities, including an intrinsics interface for AArch64 SVE/SVE2, LLVM IR Codegen for scalable vectors, and several loop-vectorization

On Nov 14, 2013, at 2:32 PM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Richard Sandiford <rsandifo at linux.vnet.ibm.com> writes: >> Are you worried that adding it to PMB will increase compile time? >> The pass exits very early for any target that doesn't opt-in to doing >> scalarisation at the IR level, without even looking at the function.

Hi Richard, The discussion on llvmpipe is irrelevant. llvmpipe has its own pass manager and optimization pipe, it is not a C compiler. Nadav On Nov 15, 2013, at 3:26 AM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote: > Nadav Rotem <nrotem at apple.com> writes: >> On Nov 14, 2013, at 2:32 PM, Richard Sandiford >> <rsandifo at linux.vnet.ibm.com>

CostModule::getInstructionCost also consults TTI ( http://llvm.org/docs/doxygen/html/CostModel_8cpp_source.html#l00380). No? Jingyue On Wed, Jan 14, 2015 at 4:05 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Wed, Jan 14, 2015 at 3:54 PM, Jingyue Wu <jingyue at google.com> wrote: > >> I'm looking for APIs that compute instruction costs, and noticed

Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at

Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev

John, > This is not categorically true, no. When we make changes that require large-scale updates for downstream codebases, we do so because there’s a real expected benefit to it. For the most part, we do make some effort to keep existing source interfaces stable. While I’m at a loss to find a documented policy, I recall this thread

Nicolai, My plan is to remove getNumElements() as soon as possible. Hopefully within the next few weeks. I just made a patch on my machine that marks it deprecated, and it generates a ton of warnings. Given that some build bots build with -Werror, I don't think we can mark it deprecated unless all the usages are first removed. It occurs to me now that it might be good to mark it

Hi Richard, Thanks for working on this. We should probably move this discussion to llvm-dev because it is not strictly related to the patch review anymore. The code below is not representative of general c/c++ code. Usually only domain specific language (such as OpenCL) contain vector instructions. The LLVM pass manager configuration (pass manager builder) is designed for C/C++ compilers, not

Hi, I just wanted to give an update on the progress of this work. This morning I merged a patch to add the new vector types. I have added a FixedVectorType, as proposed below. I also added a ScalableVectorType. I found during my work that it is useful to be able to query isa<ScalableVectorType>(Ty). Additionally, I was concerned that it would become commonplace to take

----- Original Message ----- > From: "James Molloy" <James.Molloy at arm.com> > To: "Renato Golin" <renato.golin at linaro.org> > Cc: "Nadav Rotem" <nrotem at apple.com>, "Arnold Schwaighofer" <aschwaighofer at apple.com>, "Hal Finkel" > <hfinkel at anl.gov>, "LLVM Dev" <llvm-dev at

Hi Richard, Thanks for working on this. Comments below. > I don't understand the basis for the last statement though. Do you mean > that you think most cases produce better code if scalarised at the SD stage > rather than at the IR level? Could you give an example? You presented an example that shows that scalarizing vectors allow further optimizations. But I don’t think that

Hi, I am helping with the effort to implement scalable vectors in the codebase in order to add support for generating SVE code in the Arm backend. I would like to propose a refactor of the Type class hierarchy in order to eliminate issues related to the misuse of SequentialType::getNumElements(). I would like to introduce a new class FixedVectorType that inherits from