similar to: RFC: ConstantData should not have use-lists

> On 2016-Sep-24, at 15:16, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Sep 24, 2016, at 3:06 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> r261464 added a type called ConstantData to the Value hierarchy. This >> is a parent type for constants with no operands, such as i32 0 and null. >>

Hi Chris, >> Hi Chris, this was a very tempting commit to make, unfortunately it broke >> pattern matching of vectors of booleans. The problem is that a >> ConstantDataVector is only formed if the element type is one of i8, i16, etc. >> So vectors of funky types, or not so funky types like i1, are no longer >> matched. I noticed this while working on PR11948. The

On Feb 9, 2012, at 1:22 PM, Duncan Sands wrote: > Hi Chris, this was a very tempting commit to make, unfortunately it broke > pattern matching of vectors of booleans. The problem is that a > ConstantDataVector is only formed if the element type is one of i8, i16, etc. > So vectors of funky types, or not so funky types like i1, are no longer > matched. I noticed this while working

Hi Chris, this was a very tempting commit to make, unfortunately it broke pattern matching of vectors of booleans. The problem is that a ConstantDataVector is only formed if the element type is one of i8, i16, etc. So vectors of funky types, or not so funky types like i1, are no longer matched. I noticed this while working on PR11948. The good thing is that the testcase there no longer crashes

On Sat, Sep 9, 2017 at 10:18 PM, Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Sep 7, 2017, at 11:06 PM, Chris Lovett via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I'm running into some pretty bad performance in llc.exe when compiling > some large neural networks into code that contains some very large llvm::ConstantDataArrays,

On Feb 3, 2013, at 12:55 PM, Bill Wending <isanbard at gmail.com> wrote: >>> The 'align' and "cpu" attributes both have a value associated with them. The 'attr' attribute in '#1' has multiple values associated with it. (The BNF is below in the 'IR Changes' section.) Attribute groups with the same attributes in them, but in a different order,

> you can't, you can only get a ConstantAggregateZero.  This is actually kind of > annoying, and means that places expecting a ConstantArray have to remember to > also check for ConstantAggregateZero.  Perhaps there's a good reason for the > current design, but if not it would be great to eliminate this wart. Well, I think the main reason it so reduce the size of .ll / .bc when

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

Hi Anton, >> you can't, you can only get a ConstantAggregateZero. This is actually kind of >> annoying, and means that places expecting a ConstantArray have to remember to >> also check for ConstantAggregateZero. Perhaps there's a good reason for the >> current design, but if not it would be great to eliminate this wart. > Well, I think the main reason it so

----- Original Message ----- > Hi, > > I noticed that ConstantFP::get automatically returns the > appropriately > types Constant depending on the LLVM type passed in (i.e. if called > with a vector, it returns a splat vector with the given constant). > > Is there any simple way to do the inverse of this function? i.e., > given a llvm::Value, check whether it is either

Hi all. I propose to use wrapper for this kind of constant objects. Consider next code: Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx)); Constant* ArrayItem; if (!isa<ConstantAggregateZero>(C)) ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx)); else ArrayItem = ZeroInt; Code analog within wrapper: ConstOrZero

On Wed, Mar 25, 2020 at 8:52 AM Doerfert, Johannes <jdoerfert at anl.gov> wrote: > I think the solution space for the value/use-list issue might be larger > than what was mentioned so far. > > > Some random thoughts: > > If no pass ever walks the use list of a constant, except globals which > we could handle differently, we could get rid of their use-list or >

On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 3:17 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 2:33 PM,

On Tue, May 10, 2016 at 3:03 PM, Adrian Prantl <aprantl at apple.com> wrote: > > On May 9, 2016, at 4:42 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Mon, May 9, 2016 at 3:38 PM, Peter Collingbourne <peter

On Tue, May 10, 2016 at 11:45 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, May 9, 2016 at 4:42 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> >> >> On Mon, May 9, 2016 at 4:26 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >>> >>> >>> On Mon, May 9, 2016 at 3:38 PM, Peter

Hello, I noticed a bit of a gap in the current code for unions: a ConstantUnion cannot be written out to .ll. Hopefully I'm not stepping on Talin's toes by posting this, it's a fairly straightforward adaptation of the code for structs just above. Tim. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. --------------

Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: assert(C->getType() == T->getElementType() && "Initializer for vector element doesn't match vector element type!"); I would change this to: ASSERT_STRM(C->getType() == T->getElementType(), "Initializer for vector element "

On Jul 26, 2011, at 9:17 PM, Talin wrote: > Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: > > assert(C->getType() == T->getElementType() && > "Initializer for vector element doesn't match vector element type!"); > > I would change this to: > >

I notice that there's a lot of inconsistency in the various LLVM classes with respect to convenience methods. Here's some examples: For creating GEPS, IRBuilder has: CreateGEP (2 overloads) CreateInBoundsGEP (2 overloads) CreateConstGEP1_32 CreateConstInBoundsGEP1_32 CreateConstGEP2_32 CreateConstInBoundsGEP2_32 CreateConstGEP1_64 CreateConstInBoundsGEP1_64

I am writing some code to identify malloc instructions with constant request sizes and to determine the request size if it is constant. I have two questions. 1) If a malloc is for an array allocation and the array size is a ConstantExpr, how can I obtain the value of the ConstantExpr? 2) I am using the following logic to determine if the malloc is for a constant request size and to