similar to: [LLVMdev] Alloca and malloc alignment

On Tuesday 13 October 2009 04:02, Lennart Augustsson wrote: > And you really want your allocas in the entry block so they are > implemented by just stack pointer manipulation rather than calling > alloca(). The latter is slower, and there's also a bug that makes > calling alloca() not getting the alignment right (if it's > 8). Is there a bug number for that? I wonder if

And you really want your allocas in the entry block so they are implemented by just stack pointer manipulation rather than calling alloca(). The latter is slower, and there's also a bug that makes calling alloca() not getting the alignment right (if it's > 8). On Tue, Oct 13, 2009 at 9:44 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > >> On Mon, Oct 12, 2009

Hi, > On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote: >> Are there any implicit assumptions about where alloca instructions >> can appear. > > Static allocas should appear as a continuous chunk in the entry block, > otherwise other passes might make bad assumptions. an alloca can appear anywhere, but when they are outside the entry block then

Hi, 1. Does the alignment of the pointer returned by an AllocaInst depend on the instructions before it in the basic block? The 1st snippet below aligns 'a' correctly, while the 2nd one doesnt. (the method handle_args, only prints out the values of arguments, and returns argv unchanged). define i32 @main(i32 %argc, i8** %argv) nounwind { entry: %argc_addr = alloca i32

On 8 March 2010 19:51, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > 2. I notice that the setAlignment method for an AllocaInst takes an > unsigned. For 64 bit systems, alignment could potentially be larger. Is > there a reason why the alignment should be restricted to this size? > Thanks in advance > Would it ever be practical to align a stack variable to an 8 GiB

I am trying to implement some new alignment based optimisations in our target backend, and I am wondering if there a way a target can specify that 'malloc', 'realloc' and 'calloc' always return a pointer to memory that is aligned to a particular boundary? Related too, is it possible to specify that the stack pointer always points to memory which is aligned to a

I'm using configure. On Mon, Mar 9, 2009 at 5:12 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Lennart Augustsson <lennart at augustsson.net> writes: > >> Commenting out the Hello transformation I get these link errors: >> >> llvm[2]: Linking Debug Shared Library LTO.dll >>

On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev wrote: > 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev > <llvm-dev at lists.llvm.org>: > > I am trying to implement some new alignment based optimisations in our > > target backend, and I am wondering if there a way a target can specify that > > ‘malloc’, ‘realloc’ and ‘calloc’

Hi, Is there some documentation about what has not been implemented yet? I'm trying to use vectors and I just run into one thing after another that seem to be missing. (I.e., fcmp on vectors doesn't work; trying to do the same thing with expanded instructions doesn't work; select on a vector doesn't work) -- Lennart

On Jan 24, 2009, at 4:34 AM, Lennart Augustsson <lennart at augustsson.net> wrote: > Hi, > > Is there some documentation about what has not been implemented yet? I've started adding notes to docs/LangRef.html Historically this document has been used to describe just the LLVM IR, and not what specific consumers of it do or don't support, but codegen is a very

Commenting out the Hello transformation I get these link errors: llvm[2]: Linking Debug Shared Library LTO.dll c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/Debug/lib/libLLVMSystem.a(Signals.o): In function `Z28LLVMUnhandledExceptionFilterP19_EXCEPTION_POINTERS': c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/lib/System/Win32/Signals.inc:164: undefined reference to

Lennart Augustsson <lennart at augustsson.net> writes: > Commenting out the Hello transformation I get these link errors: > > llvm[2]: Linking Debug Shared Library LTO.dll > c:/DOCUME~1/1312888/Desktop/Workspace/llvm/llvm-top/Debug/lib/libLLVMSystem.a(Signals.o): > In function `Z28LLVMUnhandledExceptionFilterP19_EXCEPTION_POINTERS': >

I am working on a custom LLVM backend for a 16 bit architecture. For my architecture, I need smaller array alignments for arrays created on the stack. For example, consider the following code at the start of a C function: char localBuff[20]; char localBuff2[6]; this gets converted by Clang into this: %localBuff = alloca [20 x i8], align 16 %localBuff2 = alloca [6 x i8], align 1 Note

Hi everyone, We have noticed that the SROA pass will only eliminate 'alloca' instructions if those are located in the entry basic block of a function. As a general recommendation, should the LLVM IR emitted by our compiler always place 'alloca' instructions in the entry basic block ? (I couldn't find any recommendations concerning this matter.) In addition, we have noticed

Like this: llvm[1]: Compiling Signals.cpp for Debug build In file included from Signals.cpp:33: Win32/Signals.inc:262: error: `sys' has not been declared Win32/Signals.inc: In function `void AddSignalHandler(void (*)(void*), void*)': Win32/Signals.inc:266: error: `KillSigs' was not declared in this scope Win32/Signals.inc:266: error: `KillSigsEnd' was not declared in this scope

On Fri, Jul 18, 2008 at 6:45 AM, Benedict Gaster <benedict.gaster at amd.com> wrote: > Consider the following C code: > > typedef __attribute__(( ext_vector_type(2) )) float float2; > typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) AFAIK, the aligned attribute doesn't do anything on a typedef of anything other than a struct/union type in either

Hi, Comments inline. Ben On 18/07/2008 16:30, "Eli Friedman" <eli.friedman at gmail.com> wrote: > On Fri, Jul 18, 2008 at 6:45 AM, Benedict Gaster > <benedict.gaster at amd.com> wrote: >> Consider the following C code: >> >> typedef __attribute__(( ext_vector_type(2) )) float float2; >> typedef __attribute__(( ext_vector_type(2) ))

Lennart Augustsson mentioned on his blog that he got substantial performance improvements by conveying to LLVM when external functions (e.g. tanh) were pure. How is this done? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

Dale Johannesen wrote: > On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > >> If <NumElements> is zero, what is the behavior of malloc() and >> alloca()? >> Can I call free() using the pointer that malloc() returns? > > alloca is not standard. > The behavior of malloc is covered in 7.20.3p1: > > If the size of the space requested is zero, the

Consider the following C code: typedef __attribute__(( ext_vector_type(2) )) float float2; typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) float float2_align2; void foo(void) { const float * p; size_t offset; float2 tmp = *((float2_align2 *)(p+offset)); } When compiled with clang ‹emit-llvm I get: define void @foo() { entry: %p = alloca float*, align 4