similar to: [LLVMdev] Incompatible types at call site

%tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; <%struct.TypHeader*> [#uses=1] the 3rd parameter is now used in an srem statement. How do we know what value is used? Does this use decide whether the value is sign extended or zero

Hi Arushi, > For a call like this, > > %tmp6 = call i32 (...)* bitcast (i32 (i8*, i8, i8**)* @ssplit to i32 (...)*)(i8* > %tmp599, i32 46, i8** %domainv3) nounwind ; <i32> > > does the 2nd argument get zero extended or sign extended? neither since it does not have the zext or sext attribute. Ciao, Duncan.

Hi Arushi, > %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* > (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* > (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; > <%struct.TypHeader*> [#uses=1] > > the 3rd parameter is now used in an srem statement. How do we know what value is > used? Does this use

On Tue, Apr 5, 2011 at 1:44 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi, > > > %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* >> (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* >> (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 >> ; >> <%struct.TypHeader*> [#uses=1]

Unoptimized IR %tmp63 = call %struct.TypHeader* (...)* bitcast (%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic to %struct.TypHeader* (...)*)(%struct.TypHeader* %tmp62, i64 %tmp24, i32 1) nounwind, !dbg !907 ; <%struct.TypHeader*> [#uses=1] Optimized IR %tmp63 = call%struct.TypHeader* (%struct.TypHeader*, i64, i64)* @Cyclotomic (%struct.TypHeader* %tmp62, i64 %tmp24,

Hi, I want to clone a given function, and add an argument to it. I then want to add a call to that new function. I have a callInstruction CI, which I want to transform to call this new function, and to take a new argument. The code I added was as follows CI->getCalledFunction()->dump(); Function* DirectF = CloneFunction(CI->getCalledFunction());

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

Hi Arushi, > I got this from C code compiled by llvm-gcc. > > There is a consistent prototype for the function > > TypHandle Cyclotomic ( hdRes, n, m ) > TypHandle hdRes; > long n, m; > > the call looks as follows, > hdI = ProdCyc( hdI, Cyclotomic( HdResult, n, 1 ) ); I bet the call occurs before the function is defined.

Hi Arushi, > When it asks for the castOpcode, it assumes both types are unsigned(indicated by > the false arguments). > > Is it correct to assume this? yes, because the behaviour of the original code was undefined. Ciao, Duncan. PS: This is the sort of thing that happens when a function is declared with a prototype such as void *Cyclotomic(void *, long, int) but the function

On Wed, Apr 6, 2011 at 8:35 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi, > > > I got this from C code compiled by llvm-gcc. >> >> There is a consistent prototype for the function >> >> TypHandle Cyclotomic ( hdRes, n, m ) >> TypHandle hdRes; >> long n, m; >> >> the call looks

On Wed, Apr 6, 2011 at 1:41 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Arushi, > > > When it asks for the castOpcode, it assumes both types are >> unsigned(indicated by >> the false arguments). >> >> Is it correct to assume this? >> > > yes, because the behaviour of the original code was undefined. > > Ciao, Duncan. > >

On 2/22/11 1:31 PM, Arushi Aggarwal wrote: > Hi, > > I want to clone a given function, and add an argument to it. I then > want to add a call to that new function. I have a callInstruction CI, > which I want to transform to call this new function, and to take a new > argument. If I understand correctly, you're cloning the function first and then adding a new argument to

Hi Arushi, > I got this from C code compiled by llvm-gcc. > > There is a consistent prototype for the function > > TypHandle Cyclotomic ( hdRes, n, m ) > TypHandle hdRes; > long n, m; I just remembered that Kernighan and Ritchie style declarations like this don't have the semantics you might expect. In particular this is not

I tried llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so --help But this does not show my pass. It says it is an unknown command line argument. Arushi On Thu, May 12, 2011 at 11:21 AM, John Criswell <criswell at illinois.edu> wrote: > On 5/12/11 11:17 AM, Arushi Aggarwal wrote: >> >> What is the correct way to register/run a machine

Dear all I use R for Windows 2.3.1 on a fully updated Windows XP Home SP2 machine and I have two related regular expression problems. platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status major 2 minor

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]

On 5/12/11 11:46 AM, Arushi Aggarwal wrote: > I tried > llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so > --help > > But this does not show my pass. It says it is an unknown command line argument. I'm assuming you've looked at other MachineFunctionPass'es and have registered yours in the same way that they do. I don't think

What is the correct way to register/run a machine function pass, so that it can be dynamically loaded? Thanks, Arushi

Replace list_entry with list_{next/prev}_entry. Arushi Singhal (2): gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry drivers/gpu/drm/drm_lease.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- changes in v2 *All the

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =