similar to: [LLVMdev] global alignment

On Aug 14, 2012, at 7:31 AM, Baozeng wrote: > Hello all, > I found that the alignment for stack value has no limitation, but for global value, it has a limitation. > > Here is an example: > > #include <stdio.h> > #include <stdlib.h> > > char x[4000] __attribute__((aligned(4096))); > > int > main (int argc, char ** argv) { > char y[4000]

On 8/14/12 12:19 PM, John McCall wrote: > On Aug 14, 2012, at 7:31 AM, Baozeng wrote: >> Hello all, >> I found that the alignment for stack value has no limitation, but for global value, it has a limitation. Baozen, with what version of LLVM did you do the following test? Was it LLVM mainline? >> >> Here is an example: >> >> #include <stdio.h>

Hell all, I am doing some research work on protecting Xen''s data structures. I know there is a direct-map area(about 12M), in which we can get the physical address of the data structure from its virtual address. My question is : are the stack and the heap of Xen both located in this direct-map area? Since I need protect stack and heap data, so it is easy to identify their physical

Hello all, I notice in previous gsocs of LLVM , there is no projects about language bindings for LLVM. Does that mean it has lower priority than other projects? Current python bindings for LLVM in the trunk are far from complemte. So I would like to improve python bindings for LLVM this summer if possible. My work will be based on llvm-py project ( http://code.google.com/p/llvm-py/). I obtained

> Please look at the thread "Python bindings in tree" starting on 2012-03-16. > There are at least four Python binding projects currently running. (None of > them in GSoC) > > I think it's a great idea to improve llvm-py, but I'd also suggest to first > look at the other bindig projects. > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/thread.html

Dear LLVM developers: Here is my another proposal of LLVM. Any suggestion would be welcome! * ** * *** Integrate Baggy Bounds Checking into SAFECode*** * * *Abstract:** * Baggy Bounds Checking (BBC) is an efficient bounds checking technique that pad and align objects to powers of two and enable allocation bounds. It uses a contiguous array as bounds table to enable

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

Is there a way using llvm::TargetData to determine the alignment of what would be equivalent to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the target platform so that I know what the max alignment of an address returned by malloc(...) will be. Thanks in advance Garrison

Sorry as you interpreted I meant minimum alignment. My issue is in translating from a C struct which has a member aligned with __attribute__((__aligned__)) to a generated packed StructType where I use padding to force the alignment of said member. Instances of this struct are placed on the heap via malloc. Although I'm currently using static C code to determine the padding size, I'm

On Feb 1, 2010, at 12:01 PM, Garrison Venn wrote: > Sorry as you interpreted I meant minimum alignment. > > My issue is in translating from a C struct which has a member aligned with > __attribute__((__aligned__)) to a generated packed StructType where I use padding > to force the alignment of said member. Instances of this struct are placed on the heap > via malloc. Although

On Feb 1, 2010, at 11:06 AM, Garrison Venn wrote: > Is there a way using llvm::TargetData to determine the alignment of what would be equivalent > to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the > target platform so that I know what the max alignment of an address returned by malloc(...) will > be. Not currently. The alignment

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

(Sorry for the duplicate mail, Richard, I accidentally sent a copy only to you before.) On Thu, Jan 14, 2016 at 10:26 PM, Richard Smith via cfe-dev < cfe-dev at lists.llvm.org> wrote: > [1]: That's not completely true, as it's possible to create an object > that is underaligned for its type: > > struct __attribute__((packed)) A { > char k; > struct B { int n;

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

The ring element addresses are passed between components with different alignments assumptions. Thus, if guest/userspace selects a pointer and host then gets and dereferences it, we might need to decrease the compiler-selected alignment to prevent compiler on the host from assuming pointer is aligned. This actually triggers on ARM with -mabi=apcs-gnu - which is a deprecated configuration, but it

The ring element addresses are passed between components with different alignments assumptions. Thus, if guest/userspace selects a pointer and host then gets and dereferences it, we might need to decrease the compiler-selected alignment to prevent compiler on the host from assuming pointer is aligned. This actually triggers on ARM with -mabi=apcs-gnu - which is a deprecated configuration, but it

Hi Elena, You're correct. LLVM does not align the stack to 32-bytes for AVX and unaligned moves should be used for YMM spills. I wrote some code to align the stack to 32-bytes when AVX spills are present; it does break the x86-64 ABI though. If upstream would be interested in this code, I can arrange with my employer to send a patch to the mailing list. -Cameron On Mar 1, 2012, at 4:09 PM,

On Mon, Apr 06, 2020 at 09:34:00PM +0800, Jason Wang wrote: > > On 2020/4/6 ??8:50, Michael S. Tsirkin wrote: > > The ring element addresses are passed between components with different > > alignments assumptions. Thus, if guest/userspace selects a pointer and > > host then gets and dereferences it, we might need to decrease the > > compiler-selected alignment to

On Mon, Apr 06, 2020 at 09:34:00PM +0800, Jason Wang wrote: > > On 2020/4/6 ??8:50, Michael S. Tsirkin wrote: > > The ring element addresses are passed between components with different > > alignments assumptions. Thus, if guest/userspace selects a pointer and > > host then gets and dereferences it, we might need to decrease the > > compiler-selected alignment to

With Debug mode, it shows the assert error: Assertion failed: (I != BlockLiveness.end() && "Predecessor not found"), function calculateLocalLiveness, file lib/CodeGen/StackColoring.cpp, line 782. 1. <eof> parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'busybox/archival/libarchive/decompress_bunzip2.c'. 4. Running