similar to: [LLVMdev] SPEC 2006 Makefile

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 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 =

Hi, I believe shouldHaveNodeForValue() should return false for ConstantPointerNullValue. Fixed in r121707. Arushi On Mon, Dec 13, 2010 at 12:10 PM, Kevin Streit <kevin.streit at googlemail.com>wrote: > I'm using BUDataStructures... But I tried LocalDatastructures and it didn't > work either... > On Dec 13, 2010 6:52 PM, "Arushi Aggarwal" <arushi987 at

FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg flag to Clang. Applies against mainline. (As discussed, va_arg isn't really supported well so this probably doesn't work well on anything other than simple code, YMMV, etc) ~Will On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Have these changes made it to mainline? Is

Hi, 1. Does the alignment of the pointer returned by an AllocaInst depend on the instructions before it in the basic block? The 1st snippet below aligns 'a' correctly, while the 2nd one doesnt. (the method handle_args, only prints out the values of arguments, and returns argv unchanged). define i32 @main(i32 %argc, i8** %argv) nounwind { entry: %argc_addr = alloca i32

1. You should run the passes in the same opt command, for passes like loops which is an analysis pass provides results to the following passes. 2. You can pass a -debug flag to opt to see the some debugging info. 3. I tried this opt -mem2reg -loops -loopsimplify -loop-unroll -unroll-count=3 -debug loop.o -o tt.bc and got this message. Loop Size = 14 Can't unroll; loop not terminated by

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

On Aug 17, 2011, at 11:53 AM, Will Dietz wrote: > FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg > flag to Clang. > > Applies against mainline. > > (As discussed, va_arg isn't really supported well so this probably > doesn't work well on anything other than simple code, YMMV, etc) > > ~Will > > On Thu, May 12, 2011 at 12:29 PM,

To get clang to emit va_arg instructions for va_arg() calls, as opposed to manually lowering it in the frontend, same as the llvm-gcc patch sent earlier does. ~Will On Wed, Aug 17, 2011 at 2:41 PM, Eric Christopher <echristo at apple.com> wrote: > > On Aug 17, 2011, at 11:53 AM, Will Dietz wrote: > >> FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg

Do you compile this as C? In C, unlike in C++, empty parenthesis do not mean "no arguments", they mean "no prototype", which is typically treated the same way as varargs in calling conventions. To declare function with no arguments do typedef void (*FP)(void); Eugene On Wed, Apr 21, 2010 at 10:22 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Hi all, > >

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

Hi all, I had the following function that used function pointers with void arguments, typedef void (*FP)(); void foo() { printf("hello world from foo\n"); } int main() { FP fp; fp = foo; (*fp)(); } The corresponding bitcode, with no optimizations is target datalayout =

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;

On 8 March 2010 19:51, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > 2. I notice that the setAlignment method for an AllocaInst takes an > unsigned. For 64 bit systems, alignment could potentially be larger. Is > there a reason why the alignment should be restricted to this size? > Thanks in advance > Would it ever be practical to align a stack variable to an 8 GiB

On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > 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                

Hi, Is the RegisterPass interface still supported, or do we have to use the INITIALIZE_PASS construct to register passes? Thanks, Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110516/98bc0ab0/attachment.html>

Hi, 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? Thanks, Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL:

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]

Thanks John. You are right. Is this also true for constant GEP expressions? Do they also create a pointer to the calculated type? The language manual does not state so explicitly. Arushi On Thu, Feb 24, 2011 at 10:47 AM, John Criswell <criswell at illinois.edu>wrote: > On 2/24/11 10:39 AM, Arushi Aggarwal wrote: > >> Given 2 GEPs as follows, >> >> %tmp124 =

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] %199 = add i64 %198, %197 ; <i64> [#uses=1] %200 = inttoptr i64 %199 to i8* ; <i8*>