similar to: [LLVMdev] allocating an array

On Wed, Jul 16, 2008 at 11:07 AM, HyperQuantum <hyperquantum at gmail.com> wrote: > How can I allocate an array with a size that is not known at compile time? > > The language reference says that the array size must be a constant > integer value. It also says that variable sized arrays are represented > by using zero as the number of elements. Obviously I cannot use zero >

On Wed, Jul 16, 2008 at 8:19 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Wed, Jul 16, 2008 at 11:07 AM, HyperQuantum <hyperquantum at gmail.com> wrote: >> How can I allocate an array with a size that is not known at compile time? > Do you mean a variable length array (as in C99) or something else? I guess I should have explained what I'm trying to do.

> if the length is %n, you can alloca %n i8's: > %x = alloca i8, i32 %n If the array element type is i32 (like the size field), then you may as well use an alloca i32; if you use an alloca i8 then you would have to use 4*%n rather than %n in order to get the right amount of memory. Ciao, Duncan.

Hello, I want to compile a LLVM file into an executable running on ARM platform. I use LLVM 2.0 with the following command lines: llvm-as -f -o test.bc test.ll llc -march=arm -mcpu=arm1136j-s -mattr=+v6 -f -o test.s test.bc arm-linux-gnu-as -mcpu=arm1136j-s test.s With the last command, I obtain the following error: rd and rm should be different in mul The bad instruction is

The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing that it abstracts implementation details, in particular pointer size, from the compiler. While it does this fine for pointer addresses, it does not manage it for address offsets. Consider the following code: $ cat test.c int main() { int *x[2]; int **y = &x[1]; return (y - x); } $ llvm-gcc -O3 -c test.c

I am seeing the wf loop get optimized just fine with llvm 2.8 (and almost as good with head). I'm running on Mac OS X 10.6. I have an apple supplied llvm-gcc and a self compiled llvm 2.8. When I run $ llvm-gcc -emit-llvm -S M.c $ opt -O2 M.s | llvm-dis I see that: 1. Tail recursion has been eliminated from wf 2. The accesses to sp have been promoted to registers 3. The loop has

Hi Mikael, You are obtaining warning, not an error, right? The most arm cores, including arm1136, can execute mul with rd = rm. So, you can ignore this warning. Lauro 2007/6/12, Peltier, Mikael <m-peltier at ti.com>: > > > > > Hello, > > > > I want to compile a LLVM file into an executable running on ARM platform. > > I use LLVM 2.0 with the following

On Fri, May 2, 2008 at 1:22 PM, Marc de Kruijf <dekruijf at cs.wisc.edu> wrote: > The LLVA and LLVM papers motivate the GetElementPtr instruction by arguing > that it abstracts implementation details, in particular pointer size, from > the compiler. While it does this fine for pointer addresses, it does not > manage it for address offsets. Consider the following code: > >

Hi, > Obviously this is wrong, but I don't see how I can use the value from > 'size' to allocate the necessary space for this array with alloca. I > could use a pointer to an array in the struct type, instead of a > direct array, and use two allocas (one for the struct and one for the > array data). But then there is no real reason to use the array type > anymore, a

Thanks, Bill and Duncan, for your suggestions. I've changed my approach, and use a pointer instead of an array now. So this code: var size : nat = 9 var x : [size] int now becomes: %size = alloca i32 ; <i32*> [#uses=2] store i32 9, i32* %size %x = alloca { i32, i32* } ; <{ i32, i32* }*> [#uses=6] load i32* %size ; <i32>:1 [#uses=1]

On Mon, Jan 27, 2020 at 4:31 PM Eli Friedman <efriedma at quicinc.com> wrote: > I assume by “drop support”, you mean reject it in the bitcode reader/IR > parser? We can’t reasonably support a complex feature like inalloca if > nobody is testing it. If we can’t reasonably upgrade it, and we don’t think > there are any users other than clang targeting 32-bit Windows, probably

On Jun 29, 2010, at 7:08 AM, ether zhhb wrote: > > why computeSCEVAtScope not try to get the operands in the current > scope like the function do with SCEVCommutativeExpr, like: > > if (const SCEVAddRecExpr *AddRec = dyn_cast<SCEVAddRecExpr>(V)) { > if (!L || !AddRec->getLoop()->contains(L)) { > ... > // Then, evaluate the AddRec. >

Sorry for the delay. Arthur Eubanks has started working on the design here: https://reviews.llvm.org/D74651 I felt I should follow up here about that. On Mon, Jan 27, 2020 at 6:47 PM Eli Friedman <efriedma at quicinc.com> wrote: > It doesn’t seem like multiple call sites should be a problem if they’re > sufficiently similar? If the argument layout for each callsite is the > same,

hi all, i have SCEVAddRec {{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1> where Loop0 and Loop1 are brothers (loops at the same level of the loopnest), and Loop0 have a computable backedge taken count. when i call getSCEVAtScope({{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1> , Loop1), it just give me a {{(32 + @edge.8265),+,32}<Loop0>,+,4}<Loop1>, instead of

Hi Chris, Thanks for your reply. You said that scalarRepl gets shy about loads and stores of the entire aggregate. Then I use a test case: ; ModuleID = 'test1.ll' define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly { %stackArray = alloca <4 x i32> %XC = bitcast i32* %X to <4 x i32>* %arrayVal = load <4 x i32>* %XC store <4 x i32>

On Sat, Nov 1, 2008 at 12:50 AM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 31, 2008, at 2:04 PM, Óscar Fuentes wrote: >> There is no reason to include the CMake build system on this >> release. It >> is undocumented and immature. >> >> Please remove the cmake/ directory and all files named CMakeLists.txt >> from the LLVM source tree.

Hi Fan, > You said that scalarRepl gets shy about loads and stores of the entire > aggregate. Then I use a test case: > > ; ModuleID = 'test1.ll' > define i32 @fun(i32* nocapture %X, i32 %i) nounwind uwtable readonly { > %stackArray = alloca <4 x i32> > %XC = bitcast i32* %X to <4 x i32>* > %arrayVal = load <4 x i32>* %XC > store

Hello all, A few years ago, I added the inalloca feature to LLVM IR so that Clang could be C++ ABI compatible with MSVC on 32-bit x86. The feature works, but there is room for improvement. I recently took the time to write up a design using token values that will hopefully be better named and easier to work with and around. For the technical details of the proposal, I've written up the RFC

Hi, Pardon me if the terminology I use is off, I'm new to this. Given a statement int a[10]; llvm-gcc generates the following alloca instruction: %a = alloca [10 x i32] This is different than the type of instruction generated by the AllocaInst constructor, which is of the type: %a = alloca i32, i32 10 Now, how do I go about extracting '10' as the array size from the first alloca

Yes, I know this works peachy keen for char arrays. I'm looking at (which is hard to express in C) something like void foo () { int bar[20] = { 42, 42, ..., 42 }; } I don't want to do a memcopy of the 20 element constant array, and memset doesn't work here. I want an intrinsic that copys the scalar int constant 42 to each element of the int array. bagel On 11/10/2016 03:30