similar to: [LLVMdev] Can't invoke an intrinsic?

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

Here's a working testcase: ; ModuleID = '/tmp/crtbegin.bc' target datalayout = "E-p:32:32:128-i1:8:128-i8:8:128-i16:16:128-i32:32:128-i64:32:128-f32:32:128-f64:64:128-v64:64:64-v128:128:128-a0:0:128-s0:128:128" target triple = "spu" @__dso_handle = hidden global i8* null, align 16 ; <i8**> [#uses=0] @__CTOR_LIST__ = internal global [1 x void

In the following IR module: – define i8 @foo() #0 { entry: %call0 = call i8 @bar() ret i8 %call0 } declare i8 @bar() #1 – @bar() gets marked as its own user in top-of-tree LLVM. I patched the Verifier to check it (but didn’t commit the patch): – Index: lib/IR/Verifier.cpp =================================================================== --- lib/IR/Verifier.cpp (revision 203468) +++

I thought I'd share a little bit of progress I made this weekend. I've gotten the first interesting test-case (a simple switch) through hyperblock-based DAGISel, and there's a pretty picture too! Each part of the switch is emitted directly into the DAG, rather than being deferred. This is the function: define i32 @foo(i32 %x, i32 %z) nounwind { entry: switch i32 %x,

Hi, The checking about that if this is a terminator that it is at the end of the block has been applied twice (bellow). One is at Verifier::visitInstruction, and the other is at Verifier::visitTerminatorInst. Since visitInstruction is called when visiting each instruction, the checking at visitTerminatorInst seems redundant to me. Did I miss any case? void Verifier::visitInstruction(Instruction

According to the docs, InsertBranch should only be called if AnalyzeBranch returns success. But in targets (like ARM or Sparc) that don't implement them, the following test fails: ----------------------------------- void %__gcov_init() { entry: switch uint 0, label %cond_true.i [ uint 0, label %UnifiedReturnBlock uint 875573313, label

Very nice! Why did you decide on hyperblock instead of SEME region and how are you forming the blocks? Evan On Apr 20, 2008, at 9:59 PM, Christopher Lamb wrote: > I thought I'd share a little bit of progress I made this weekend. > I've gotten the first interesting test-case (a simple switch) > through hyperblock-based DAGISel, and there's a pretty picture too! >

Hi, I'm working on the iterated register coalescing graph coloring allocator and try to test it with all backends available currently in LLVM. Initial tests with most of the backends are successful. It turned out that my allocator triggers a specific assertion in the RegScavenger and only for the ARM target. It looks like the LR register is used for frame pointer related things, but it is

Hi Warren, You have the -m32 flag set, but it's still giving you this: > Warning: Generation of 64-bit code for a 32-bit processor requested. > Warning: 64-bit processors all have at least SSE2. But are you sure you want to compile the LLVM-GCC source? You should use the binaries unless absolutely necessary. -bw On May 24, 2007, at 10:34 PM, Warren Armstrong wrote: > Hi all,

Hi Warren, you can try to configure with the following export CFLAGS="-m64" export LDFLAGS="-L/usr/lib64" LLVM: ../src/configure --prefix=`pwd`../install --enable-optimized --enable-jit --enable-targets=host-only make LLVM-GCC: ../llvm-gcc4-2.0.source/configure --prefix=`pwd`../install --program-prefix=llvm- --enable-llvm=/home/warren/llvm/obj/ --enable-languages=c,c++

I'm attempting to modify a parser generator to emit LLVM code instead of C. So far the experience has been trivial, but I am now running into an error regarding labels that I can't seem to solve. Situation 1: A label is used immediately after a void function call (l6 in this case): <snip> %tmp26 = load i32* @yybegin, align 4 %tmp27 = load i32* @yyend, align 4 call void

<<< I may misunderstand, but it seems to me that this solves only query for aliasing with a pointer known to be pointing only to globals defined in the current compilation unit. For any pointer which "may point somewhere else”, you won’t be able to resolve the non-aliasing with the “internal state” for malloc/free, right? To take the original example in this thread: int *x =

Hi, This email is in continuation to the mail thread http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html, to propose a new function attribute that can convey that a function maintains state, but this state is inaccessible to the rest of the program under compilation. Such a flag could be added to most libc/system calls such as printf/malloc/free. (libc and system calls do

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Joseph Tremoulet" <jotrem at microsoft.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 1:28:05 PM > Subject: Re: [llvm-dev] RFC: New function attribute

>is this "internal state” supposed to be private to the function? It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state. >how this flag would prevent the last “optimization”

>but is there or is there not accessible, visible state, Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means it doesn't access any of the visible (accessible) states. - Vaivaswatha On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I don't think the attribute as is is strong enough to do what you

Hi LLVM, In lib/VMCare/Verifier.cpp::visitInstruction, we have such code 1287 // Check that the return value of the instruction is either void or a legal 1288 // value type. 1289 Assert1(I.getType() == Type::getVoidTy(I.getContext()) || 1290 I.getType()->isFirstClassType() 1291 || ((isa<CallInst>(I) || isa<InvokeInst>(I)) 1292 &&

On 1/18/17 3:55 PM, Davide Italiano via llvm-dev wrote: > On Tue, Jan 17, 2017 at 6:02 PM, Mikhail Zolotukhin > <mzolotukhin at apple.com> wrote: >> Hi, >> >> Continuing recent efforts in understanding compile time slowdowns, I looked at some historical data: I picked one test and tried to pin-point commits that affected its compile-time. The data I have is not 100%

I have created the function prototype with the following code: const uintmax_t methodNameSize = 1024; const char methodNameTemplate[] = "llvm.memcpy.p0i%llu.p0i%llu.i%llu"; char methodName[methodNameSize]; // Create the methodName. memset(methodName, 0, methodNameSize); sprintf(methodName, methodNameTemplate, dstSize, srcSize, lengthSize); // Search for the

Hi Victor, this code from the verifier broke the Ada front-end build: const Module* M = CI.getParent()->getParent()->getParent(); Constant *MallocFunc = M->getFunction("malloc"); if (CI.getOperand(0) == MallocFunc) { const PointerType *PTy = PointerType::getUnqual(Type::getInt8Ty(CI.getParent()->getContext())); Assert1(CI.getType() == PTy, "Malloc