search for: numel

...This is quite a simple question so hopefully it's easy to answer. I was looking at the documentation for the alloca instruction ( http://llvm.org/docs/LangRef.html#alloca-instruction ) and something is unclear to me. The given syntax is... <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result And the documentation states "The ‘alloca‘ instruction allocates sizeof(<type>)*NumElements bytes of memory on the runtime stack". It is not stated how the "<ty>" type is used as we are told the type of...

Thanks for the reply. Please see my inline responses. On 15/08/13 12:58, Tim Northover wrote: > Hi Dan, > >> It is not stated how the "<ty>" type is used as we are told the >> type of result is type* and sizeof(<type>)*NumElements is the >> amount of memory so from my perspective it looks like <ty> is >> never used which would seem to make stating i32 twice in the >> following example redundant >> >> %ptr = alloca i32, i32 4 >> >> My guess is that if <NumElements>...

...tor<int, 8>& values) { if (llvm::ConstantVector* constantVector = llvm::dyn_cast<llvm::ConstantVector>(value)) { // get components llvm::SmallVector<llvm::Constant*, 8> elements; constantVector->getVectorElements(elements); int numElements = int(elements.size()); for (int i = 0; i < numElements; ++i) { if (llvm::ConstantInt* element = llvm::dyn_cast<llvm::ConstantInt>(elements[i])) values[i] = int(element->getZExtValue()); } } } at the end of InstCombi...

...null, the operation is valid >> but does not free the pointer." > > It isn't though. free(NULL) could segfault the app, for example. See Nick's post. >> Regarding malloc and alloca, I realized that the size is unsigned, >> so a >> negative value for NumElements is impossible. I suggest replacing "it >> is the number of elements allocated" with "it is the UNSIGNED number >> of >> elements allocated". > > I'm not sure why this is more clear. The semantics of malloc and alloca depend on whether you i...

Hi all, Quoting <http://llvm.org/docs/LangRef.html#i_malloc>: The 'malloc' instruction allocates sizeof(<type>)*NumElements bytes of memory from the operating system and returns a pointer of the appropriate type to the program. If "NumElements" is specified, it is the number of elements allocated. Obviously this does not say that the default for NumElements is one. Even obvious assumptions should b...

Chris Lattner wrote: > On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote: >>>> Regarding malloc and alloca, I realized that the size is unsigned, >>>> so a >>>> negative value for NumElements is impossible. I suggest replacing >>>> "it >>>> is the number of elements allocated" with "it is the UNSIGNED number >>>> of >>>> elements allocated". >>> I'm not sure why this is more clear. >> The sem...

On Apr 19, 2008, at 3:27 PM, Jon Sargeant wrote: >>> Regarding malloc and alloca, I realized that the size is unsigned, >>> so a >>> negative value for NumElements is impossible. I suggest replacing >>> "it >>> is the number of elements allocated" with "it is the UNSIGNED number >>> of >>> elements allocated". >> >> I'm not sure why this is more clear. > > The semantics of...

I do not have a strong opinion on the naming of the various size functions, or on how to deal with APInt's of sizes that are not multiples of a byte. I do think loading and storing more bytes than necessary is generally a bad idea, especially if you're getting uninitialized bits. (If you incorrectly cross a page boundary, you might fault, for one thing. Watch out for packed

...nas Paulsson via llvm-dev wrote: >> Hi, >> >> I wonder why getScalarizationOverhead() does not take into account >> the number of operands of the instruction? This should influence the >> number of extracts needed, so instead of >> >> Scalarization cost = NumEls * (insert + extract) >> >> it would be better to do >> >> Scalarization cost = NumEls * (insert + (extract * numOperands)) > > I suspect this is an oversight (although we need to be a bit careful > here because if two operands are the same, which is not uncommon,...

...il/llvm-commits/Week-of-Mon-20080331/060556.html > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping trailing whitespace. > > -Chris > Hmm, I realized that the alignment doesn't have a type in front of it (unlike NumElements) so it's reasonably clear that it's a constant. Saying "constant alignment" isn't necessary. Regarding malloc, I think your wording isn't clear enough: "Allocating zero bytes is undefined." My understanding is that an undefined operation is illegal; ho...

Hi, I wonder why getScalarizationOverhead() does not take into account the number of operands of the instruction? This should influence the number of extracts needed, so instead of Scalarization cost = NumEls * (insert + extract) it would be better to do Scalarization cost = NumEls * (insert + (extract * numOperands)) / Jonas

...round of changes. Please verify that they >>> are correct. >> >> Applied with edits: >> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060556.html >> > Hmm, I realized that the alignment doesn't have a type in front of it > (unlike NumElements) so it's reasonably clear that it's a constant. > Saying "constant alignment" isn't necessary. It doesn't hurt. > Regarding malloc, I think your wording isn't clear enough: "Allocating > zero bytes is undefined." My understanding is that an...

...) when converting constant arrays to strings. Consider the following example: std::string Text = "HelloWorld"; unsigned TextLengthBefore = Text.length(); ConstantArray *pArray = dyn_cast<ConstantArray>(llvm::ConstantArray::get(pModule->getContext(), Text, true)); unsigned NumElements = pArray->getNumOperands(); Text = pArray->getAsString(); unsigned TextLengthAfter = Text.length(); After running this example here are the values in each variable: TextLengthBefore = 10 NumElements = 11 TextLengthAfter = 11 In the conversion from constant array to a string...

...where from 2 gigabytes to 4 >> gigabytes. > > Which might be exactly what it's supposed to do. Suppose you're writing > heap management code. Perhaps, but very unlikely. An allocation of 2 gigabytes or more is probably a bug. >> I'm not necessarily saying that NumElements should be >> signed, only that the choice between signed and unsigned is not obvious. > > Obviously, obviousness is in the eye of the beholder :-) > (SCNR) Yes. But consider that there are many people who agree with me. Search for "unsigned vs signed - Is Bjarne Mist...

...have the allocator check whether that much space is available - that's even better than catching nominally negative values, because it will also catch those situations where the program erroneously allocates just a quarter of the address space. > >> I'm not necessarily saying that NumElements should be > >> signed, only that the choice between signed and unsigned is not obvious. > > > > Obviously, obviousness is in the eye of the beholder :-) > > (SCNR) > > Yes. But consider that there are many people who agree with me. Search > for "...

...;=' and '*='. Sema rejects these in C89 mode because they // are not i-c-e's, so we don't need to distinguish between the two here. // Parse the constant-expression or assignment-expression now (depending // on dialect). if (getLang().CPlusPlus) NumElements = ParseConstantExpression(); else NumElements = ParseAssignmentExpression(); } As far as I can tell this code should not compile because of the following code from Ownership.h: template <ASTDestroyer Destroyer> class ASTOwningResult { … ASTOwningRe...

...) when converting constant arrays to strings. Consider the following example: std::string Text = "HelloWorld"; unsigned TextLengthBefore = Text.length(); ConstantArray *pArray = dyn_cast<ConstantArray>(llvm::ConstantArray::get(pModule->getContext(), Text, true)); unsigned NumElements = pArray->getNumOperands(); Text = pArray->getAsString(); unsigned TextLengthAfter = Text.length(); After running this example here are the values in each variable: TextLengthBefore = 10 NumElements = 11 TextLengthAfter = 11 In the conversion from constant array to a string...

.../060556.html >> >> I figured out what your patches don't apply. Something (your web browser, >> editor, etc) is stripping trailing whitespace. >> >> -Chris >> > > Hmm, I realized that the alignment doesn't have a type in front of it > (unlike NumElements) so it's reasonably clear that it's a constant. > Saying "constant alignment" isn't necessary. > > Regarding malloc, I think your wording isn't clear enough: "Allocating > zero bytes is undefined." My understanding is that an undefined >...

...warned). However, in some situations /// this is not desired so if AddNull==false then the string is copied without /// null termination. static Constant *get(LLVMContext &Context, StringRef Initializer, bool AddNull = true); Ciao, Duncan. > > unsigned NumElements = pArray->getNumOperands(); > > Text = pArray->getAsString(); > > unsigned TextLengthAfter = Text.length(); > > After running this example here are the values in each variable: > > TextLengthBefore = 10 > > NumElements = 11 > > TextLengthAfter = 11 &g...

In alloca, is it required that NumElements be a literal integer, or can it be a computed result? The real question is whether the current IR can support a one-stack implementation of Ada's dynamically sized stack frames. shap