similar to: [LLVMdev] RFC: Patch for CFA on Darwin

Bill, > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. Please ignore my prev. e-mail. The code breaks at least 32-bit stuff. The arg of

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 =

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().

I've built a debug build of llvm 2.6, and llvm-gcc 2.6 for arm-elf with --enable-checking=yes. On the attached test case (which is g++.dg/expr/bitfield4.C from the GCC 4.2 testsuite) I get: $ cc1plus bitfield4.ii -emit-llvm-bc -o bitfield4.o -quiet cc1plus: /home/foad/svn/antix/toolchain/branches/w/foad/2757llvm26/toolchain/llvm/llvm-gcc/gcc/llvm-convert.cpp:999: llvm::Value*

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) {

Hello, Bill > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. How do you like the one attached? It seems to be much more clear to fix codegen

Bill, > The built-in dwarf_cfa doesn't take an argument. It returns a pointer. Ah. Sorry for confusion: gcc's __builtin_draft_cfa doesn't have any argument LLVM's eh_dwarf_cfa intrinsic has extra "offset" argument, which is i32, because we have to propagate some information from GCC to LLVM. > But there's an offset associated with the CFA. So it looks like

Hi, I've been having some trouble implementing a new intrinsic for LLVM and I was wondering if someone might know the answer. LLVM has an llvm.returnaddress intrinsic, but for a specific project, I need to be able to modify the return address of a function as well, so I'm implementing a new intrinsic: def int_setreturnaddress : Intrinsic<[], [llvm_i32_ty, llvm_ptr_ty], []>;

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

Ok, I've tracked down the problem I've had bootstrapping llvm-gcc. The culprit is in TreeToLLVM::EmitMemCpy: void TreeToLLVM::EmitMemCpy(Value *DestPtr, Value *SrcPtr, Value *Size, unsigned Align) { const Type *SBP = PointerType::get(Type::Int8Ty); const Type *IntPtr = TD.getIntPtrType(); Value *Ops[4] = { CastToType(Instruction::BitCast,

Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c (revision 39923) +++ gcc/gimplify.c (working copy) @@ -179,8 +179,10 @@ /* LLVM LOCAL begin */ #ifndef ENABLE_LLVM /* LLVM wants to know about gimple formal temps. */ - for (t = gimplify_ctxp->temps; t ; t = TREE_CHAIN (t)) - DECL_GIMPLE_FORMAL_TEMP_P (t) = 0; + if

Hi All, While compiling libgcc with LLVM for our target, it seems I don't get __builtin_dwarf_cfa() right. That causes uw_init_context_1 [1] initialize the wrong context, and the overall exception handling fail. I find Hal provided patch years ago adding ISD::EH_DWARF_CFA, which corresponding to __builtin_dwarf_cfa(), and let us have the opportunity to handle __builtin_dwarf_cfa() for our

Looks like that break came from http://llvm.org/viewvc/llvm-project?view=rev&revision=135154 Judging by this<http://llvm.org/docs/doxygen/html/classllvm_1_1ArrayRef.html#a3b1f44186f9787d7ffacb54b62d6798c> ArrayRef ctor you should be able to simplify those calls by changing the last two arguments from "&foo, 1" to, simply, "foo". On Mon, Jul 18, 2011 at 6:59 AM,

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

That seems to work, thanks! The specific code I ended up with to call int64_t print(int64_t) looks like: auto f = builder.CreateIntToPtr( ConstantInt::get(builder.getInt64Ty(), uintptr_t(print)), PointerType::getUnqual(FunctionType::get( builder.getInt64Ty(), {builder.getInt64Ty()}, false))); return builder.CreateCall(f, args); On Mon, Mar

The option we use is to have a custom memory manager, override the getPointerToNamedFunction function, and provide the pointer to the external function at link time. The inttoptr scheme works fairly well, but it does make for some pretty ugly and sometimes hard to analyze IR. I recommend leaving everything symbolic until link time if you can. Philip On 03/28/2016 06:33 PM, Russell Wallace

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

> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Russell Wallace via llvm-dev > Subject: [llvm-dev] JIT compiler and calls to existing functions > In the context of a JIT compiler, what's the recommended way to generate a call to an > existing function, that is, not one that you are generating on-the-fly with LLVM, but > one that's already

Despite the commit of... ------------------------------------------------------------------------ r135371 | lattner | 2011-07-18 00:25:32 -0400 (Mon, 18 Jul 2011) | 2 lines untested patch to de-constify llvm::Type, patch by David Blaikie! current dragonegg svn at r135391 still fails to compile against FSF gcc 4.5.3 with the failure... In file included from

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template