similar to: [LLVMdev] MSIL backend: external varargs signatures printing

Hello, > So, looking for type of callee (not result, but function type!) you'll > obtain the > real "signature" of callee and if you'll strip all pointer cast you'll > obtain the "declaration" (=variadic) type of the callee. Maybe I misunderstood something but I just get the variadic declaration not the real "signature", like this: const

Hi, This patch allows executing code with vararg pinvoke functions under Mono. It generates separate function declaration for each call signature. Artur -------------- next part -------------- A non-text attachment was scrubbed... Name: varargs.patch Type: text/x-patch Size: 5331 bytes Desc: not available URL:

Hi, Artur > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > 123). > I was diging in doxygen documentation but I really can't see the easy way to > compare those instructions and again finish with reinvented (but working) > wheel ;). Ah, sorry. I missed that you're doing variadic calls, not casting variadic function to definite ones. I think you

Hello, I work in Kalray (Montbonnot, France) and I'm PhD student at Universite Joseph Fourier in Grenoble. We want to use LLVM framework for MSIL code generation, which is part of my thesis. Currently I'm still reading LLVM's documentation and I've started completing the MSIL backend for running on Mono. Things that need to be fixed include pointers initialization, call to

Hi Anton > > > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > > 123). > > I was diging in doxygen documentation but I really can't see the easy way > to > > compare those instructions and again finish with reinvented (but working) > > wheel ;). > Ah, sorry. I missed that you're doing variadic calls, not casting >

Artur, > OK, I just need the same signature for both of those instructions. Both are callinsts of same function, isn't that enough? Since it's a variadic function there is also a bitcast to proper type. So, looking for type of callee (not result, but function type!) you'll obtain the real "signature" of callee and if you'll strip all pointer cast you'll obtain the

Anton Korobeynikov wrote: > Hi, Artur > > >> I'm working on that backend now, so probably I'll send some more patches >> soon. I'd be grateful if you could give me some suggestions how to add >> some test for that backend to the test-suite. On Linux the output code >> could be run on Mono and compared with outputs for other backends but >>

Hi, Artur > So again, one of them makes the global pointers initialization work. > The second one allows executing code with vararg pinvoke functions under > Mono. It generates separate function declaration for each call signature. Is this mono-only feature? Or pretty "universal" one? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

On 8 Oct 2014, at 18:19, Reid Kleckner <rnk at google.com> wrote: > The one target I know about where varargs are passed differently from normal arguments is aarch64-apple-ios/macosx. After thinking a bit more, I think this forwarding thunk representation works fine even on that target. Typically a forwarding thunk is called indirectly, or at least through a bitcast, so the LLVM IR call

Hi, Artur > // CallSites have equal signatures > bool MSILWriter::cmpCallSite(CallSite A, CallSite B) { >   return (getCallSiteFType(A)==getCallSiteFType(B) && >     A.getAttributes()==B.getAttributes()); > } As it is impossible to honour argument attributes in MSIL I don't see why you should compare attributes. You seems to have the same MSIL call signature for calls

Hi Artur, Artur Pietrek wrote: > Hello, > > I work in Kalray (Montbonnot, France) and I'm PhD student at Universite > Joseph Fourier in Grenoble. > We want to use LLVM framework for MSIL code generation, which is part of > my thesis. > Currently I'm still reading LLVM's documentation and I've started > completing the MSIL backend for running on Mono.

Hello Anton > %1 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([16 x > > i8]* @.str, i32 0, i32 0), i32 %0) nounwind > > %10 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr ([11 x i8]* > > @.str2, i32 0, i32 0), i32 5) nounwind > > > > Instruction::isSameOperationAs() returns false for those two. Is it a > > bug or I misunderstood

I needed this functionality to solve http://llvm.org/PR20653, but it obviously has far more general applications. You can do it like this: define i32 @my_forwarding_thunk(i32 %arg1, i8* %arg2, ...) { ... ; define new_arg1 and new_arg2 %r = musttail call i32 (i32, i8*, ...)* @the_true_target(i32 %new_arg1, i8* %new_arg2, ...) ret i32 %r } declare i32 @the_true_target(i32, i8*, ...) The

Hi, Artur > I'm working on that backend now, so probably I'll send some more patches > soon. I'd be grateful if you could give me some suggestions how to add > some test for that backend to the test-suite. On Linux the output code > could be run on Mono and compared with outputs for other backends but > I'm not sure if it's preferable to involve third party

Hi, Here's a patch that fixes initialization of global pointers (also function pointers). I'm working on that backend now, so probably I'll send some more patches soon. I'd be grateful if you could give me some suggestions how to add some test for that backend to the test-suite. On Linux the output code could be run on Mono and compared with outputs for other backends but

I'm trying to use CallInst::Create to construct a call to a variadic function, and I'm running into the following assertion failure: /localhome/simmon12/workspace/llvm-sources/lib/VMCore/Instructions.cpp:297: void llvm::CallInst::init(llvm::Value*, llvm::Value* const*, unsigned int): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Params[i]->getType())

On Fri, Aug 21, 2009 at 12:33 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com> wrote: > > Hi All, > > Since few days I observe weird change. > > Consider the following C code > > > > char array[] = "0123456789"; > > extern int test(char arr[], int size); > >

On Fri, Aug 21, 2009 at 2:02 AM, Artur Pietrek<pietreka at gmail.com> wrote: > Hi All, > Since few days I observe weird change. > Consider the following C code > > char array[] = "0123456789"; > extern int test(char arr[], int size); > > int main(void) { >   return test(array-1, sizeof(array)-1); > } > > using clang frontend i get this: > >

Hi All, Since few days I observe weird change. Consider the following C code char array[] = "0123456789"; extern int test(char arr[], int size); int main(void) { return test(array-1, sizeof(array)-1); } using clang frontend i get this: %call = call i32 @test(i8* getelementptr inbounds ([11 x i8]* @array, i32 0, i32 -1), i32 10) ; <i32> [#uses=1] and using LLVM-GCC this: %1 =

Such as printf, etc., from IR created using the API (IRBuilder). Google hasn't provided much help, and I can't find anything relevant in the docs (the docs talk about how to do varargs in LLVM ASM, but not how to call an external vararg function that exists in a library that gets linked to the LLVM module). Is there something special I need to do? Simply calling