Displaying 14 results from an estimated 14 matches for "emitaggregatecopi".
Did you mean:
emitaggregatecopy
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 Nov 07
3
[LLVMdev] RFC: llvm-convert.cpp Patch
How about this patch then?
-bw
Index: gcc/llvm-convert.cpp
===================================================================
--- gcc/llvm-convert.cpp (revision 43658)
+++ gcc/llvm-convert.cpp (working copy)
@@ -758,7 +758,7 @@
}
-Value *TreeToLLVM::Emit(tree exp, Value *DestLoc) {
+Value *TreeToLLVM::Emit(tree exp, Value *DestLoc, unsigned Alignment) {
2013 Jan 20
2
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this
seems like an easy and simple deficiency in the IR intrinsic for memcpy.
See below.
On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison <
arnaud.allarddegrandmaison at parrot.com> wrote:
> define void @test(i16 zeroext %a) nounwind uwtable {
> %r.sroa.0 = alloca i16, align 2
> %r.sroa.1 = alloca i16,
2013 Jan 20
0
[LLVMdev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
As a results of my investigations, the thread is also added to cfe-dev.
The context : while porting my company code from the LLVM/Clang releases
3.1 to 3.2, I stumbled on a code size and performance regression. The
testcase is :
$ cat test.c
#include <stdint.h>
struct R {
uint16_t a;
uint16_t b;
};
volatile struct R * const addr = (volatile struct R *) 416;
void test(uint16_t a)
{
2007 Nov 07
0
[LLVMdev] RFC: llvm-convert.cpp Patch
On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote:
> Hi all,
>
> This patch is to fix a problem on PPC64 where an unaligned memcpy is
> generated. The testcase is this:
>
> $ cat testcase.c
> void Qux() {
> char Bar[11] = {0};
> }
>
> What happens is that we produce LLVM code like this:
>
> call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11
2008 Feb 15
0
[LLVMdev] an llvm-gcc bug
On Feb 15, 2008, at 10:27 AM, Chris Lattner wrote:
>
> On Feb 15, 2008, at 10:23 AM, Devang Patel wrote:
>
>>
>> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote:
>>
>>>>> Alternatively I can take the Padding bit into account in the
>>>>> StructType::get code somehow. Anyone have a strong opinion?
>>>>
>>>>
2007 Nov 07
7
[LLVMdev] RFC: llvm-convert.cpp Patch
Hi all,
This patch is to fix a problem on PPC64 where an unaligned memcpy is
generated. The testcase is this:
$ cat testcase.c
void Qux() {
char Bar[11] = {0};
}
What happens is that we produce LLVM code like this:
call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11
x i8]* @C.103.30698, i32 0, i32 0), i64 11, i32 8 )
Notice that it has an 8-byte alignment. However, the Bar
2008 Feb 15
3
[LLVMdev] an llvm-gcc bug
On Feb 15, 2008, at 10:23 AM, Devang Patel wrote:
>
> On Feb 15, 2008, at 10:08 AM, Chris Lattner wrote:
>
>>>> Alternatively I can take the Padding bit into account in the
>>>> StructType::get code somehow. Anyone have a strong opinion?
>>>
>>> Shouldn't it be a map from the gcc type to the padding info?
>>> That said, you can get
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
2013 Jan 21
0
[LLVMdev] [cfe-dev] codegen of volatile aggregate copies (was "Weird volatile propagation" on llvm-dev)
On 01/20/2013 10:56 PM, Chandler Carruth wrote:
> I doubt you needed to add cfe-dev here. Sorry I hadn't seen this, this
> seems like an easy and simple deficiency in the IR intrinsic for
> memcpy. See below.
>
> On Sun, Jan 20, 2013 at 1:42 PM, Arnaud de Grandmaison
> <arnaud.allarddegrandmaison at parrot.com
> <mailto:arnaud.allarddegrandmaison at
2013 Jan 18
2
[LLVMdev] Weird volatile propagation ?
Hi All,
Using clang+llvm at head, I noticed a weird behaviour with the following
reduced testcase :
$ cat test.c
#include <stdint.h>
struct R {
uint16_t a;
uint16_t b;
};
volatile struct R * const addr = (volatile struct R *) 416;
void test(uint16_t a)
{
struct R r = { a, 1 };
*addr = r;
}
$ clang -O2 -o - -emit-llvm -S -c test.c
; ModuleID = 'test.c'
target
2008 Feb 15
4
[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
Dear LLVMers
OK, when I signed up for this mailing list, I asked for a once-daily digest.
This is the fourth digest I receive today, and there are about that many
each day.
The only reason I subscribe to the mailing list is so I can post to it. But
I don't need to receive the emails, because I can fully well read them in
the archive online, and I certainly don't want to get spammed
2008 Feb 15
0
[LLVMdev] LLVMdev Digest, Vol 44, Issue 47
Here's issue 48. I'm guessing I'm going to get issue 49 as soon as I hit
send...
On Fri, Feb 15, 2008 at 3:28 PM, <llvmdev-request at cs.uiuc.edu> wrote:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via
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 =