search for: numels

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

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

Hi! currently instcombine does not detect constant diagonal matrix times vector, for example a.xx * [2 0] + a.yy * [0 3] can be optimized to a * [2 3] I have implemented this for float. I know that this assumes x * 0 = 0 which is not ieee compliant but i post it here in case it is interesting for someone. on my wish list there is still an option for target independent optimizations to have x

Thanks for your reply. Chris Lattner wrote: >> Regarding free, I also think your wording isn't clear enough: "If the >> pointer is null, the result is undefined." The free result is void. >> Consider rewording as "If the pointer is null, the operation is valid >> but does not free the pointer." > > It isn't though. free(NULL) could

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

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

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

Chris Lattner wrote: > On Mon, 31 Mar 2008, Jon Sargeant wrote: >> I'm attaching another 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 > > I figured out what your patches don't apply. Something (your web browser, > editor, etc) is stripping

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

On Apr 1, 2008, at 6:41 PM, Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another 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

Hello, I found saw some strange behavior (to me) 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 =

Joachim Durchholz wrote: > Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: >> First, I can assign -1 to >> the count to indicate an invalid or unknown value. > > This is a C-ism. In a language that supports discriminated unions well, > you'd do something like > type AllocaCount = Invalid | Unknown | Known int > (where Invalid, Unknown and Known

Am Sonntag, den 20.04.2008, 09:34 -0700 schrieb Jon Sargeant: > Joachim Durchholz wrote: > > Am Samstag, den 19.04.2008, 16:24 -0700 schrieb Jon Sargeant: > >> First, I can assign -1 to > >> the count to indicate an invalid or unknown value. > > > > This is a C-ism. In a language that supports discriminated unions well, > > you'd do something like

ParseDecl.cpp fails to compile with MSVC reporting the following error: ParseDecl.cpp compiler\llvm\tools\clang\lib\Parse\ParseDecl.cpp(2760) : error C2248: 'clang::A STOwningResult<Destroyer>::operator =' : cannot access private member declared i n class 'clang::ASTOwningResult<Destroyer>' with [ Destroyer=::up▲ ]

Hi, I haven't seen a response and I'm curious if I should submit a patch for this. Thanks, Javier From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Martinez, Javier E Sent: Friday, July 16, 2010 3:20 PM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Strange behavior when converting arrays to strings Hello, I found saw some strange behavior (to

Jon Sargeant wrote: > Chris Lattner wrote: >> On Mon, 31 Mar 2008, Jon Sargeant wrote: >>> I'm attaching another 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 >> >> I figured out what your patches don't apply. Something (your web

Hi Javier, > I found saw some strange behavior (to me) 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)); from

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