Displaying 7 results from an estimated 7 matches for "type_alignment".
2019 Dec 29
2
__c11_atomic builtins' input requirements
...# define _LIBCPP_HAS_GCC_ATOMIC_IMP
#endif
To implement atomic_ref, it might be cleaner to use the gcc builtins. By
doing so, we avoid depending on the internals of the c11 atomic builtins.
The required alignment of referenced variables would always be the first
power of 2 >= max(type_size, type_alignment). Alternatively, we could use
the c11 atomic builtins when available if it is enough to require that the
input reference is aligned as the atomic type would be. What are your
thoughts?
Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llv...
2009 Jan 09
0
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi Evan,
> LValue LV = EmitLV(lhs);
> bool isVolatile = TREE_THIS_VOLATILE(lhs);
> unsigned Alignment = expr_align(exp) / 8
>
> It's using the alignment of the expression, rather than the memory
> object of LValue.
can't you just use expr_align(lhs) instead?
> The patch saves the alignment of the memory object in LValue returned
> by EmitLV().
2009 Jun 03
1
[LLVMdev] RFA: Alignment of Strings
One of our developers pointed out that GCC generates something akin to
this on Darwin:
$ cat t.c
__private_extern__ void bar(const char *format, ...)
__attribute__ ((format (printf, 1, 2)));
void foo(const char *i, const char *b) {
bar("this is some error message that is kind of longish.");
}
$ gcc -arch i386 -S -o - t.c -Os
.cstring
.align 2
LC0:
.ascii "this is some
2009 Jan 09
2
[LLVMdev] RFC: Store alignment should be LValue alignment, not source alignment
Hi all,
Please review this patch. It's fixing PR3232 comment #8. Function bar
from 2008-03-24-BitFiled-And-Alloca.c compiles to:
%struct.Key = type { { i32, i32 } }
...
define i32 @bar(i64 %key_token2) nounwind {
entry:
%key_token2_addr = alloca i64 ; <i64*> [#uses=2]
%retval = alloca i32 ; <i32*> [#uses=2]
%iospec =
2007 Oct 26
2
[LLVMdev] RFC: llvm-convert.cpp Patch
Hi all,
The patch below is to fix a problem with unaligned memcpys. This program:
void Bork() {
int Qux[33] = {0};
}
will currently produce this LLVM code on PPC64:
@C.0.937 = internal constant [33 x i8] zeroinitializer
define void @Bork() {
entry:
%Qux = alloca [33 x i8]
%Qux1 = bitcast [33 x i8]* %Qux to i8*
call void @llvm.memcpy.i64( i8* %Qux1, i8* getelementptr ([33
x i8]*
2007 Oct 26
0
[LLVMdev] RFC: llvm-convert.cpp Patch
On Oct 26, 2007, at 11:12 AM, Bill Wendling wrote:
> Hi all,
>
> The patch below is to fix a problem with unaligned memcpys. This
> program:
>
> void Bork() {
> int Qux[33] = {0};
> }
>
> will currently produce this LLVM code on PPC64:
>
> @C.0.937 = internal constant [33 x i8] zeroinitializer
>
> define void @Bork() {
> entry:
> %Qux = alloca
2020 Jun 04
2
[cfe-dev] Clang/LLVM function ABI lowering (was: Re: [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM)
On 4 Jun 2020, at 0:54, James Y Knight via llvm-dev wrote:
> While MLIR may be one part of the solution, I think it's also the case
> that
> the function-ABI interface between Clang and LLVM is just wrong and
> should
> be fixed -- independently of whether Clang might use MLIR in the
> future.
>
> I've mentioned this idea before, I think, but never got around to