similar to: [LLVMdev] Version Compatibility

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

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

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,

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]

I should have been more specific: "Why do we want this as an option? Do we want it on all the time? Why or why not?" -eric On Aug 17, 2011, at 3:02 PM, Will Dietz wrote: > 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

Have these changes made it to mainline? Is there a way to get a patch for the backend, which does the actual lowering? Thanks, Arushi On Sun, Feb 20, 2011 at 1:54 PM, David Meyer <pdox at google.com> wrote: > Sergey, > Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". > (Note that this patch won't ever be part of llvm-gcc upstream. It will most

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 =

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

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

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

Hi, You might want to try running -loops -loop-simplify before loop unroll. >From loop simplify.cpp This pass performs several transformations to transform natural loops into a00011 // simpler form, which makes subsequent analyses and transformations simpler and00012 // more effective. Arushi On Tue, May 3, 2011 at 2:17 PM, Manish Gupta <mgupta.iitr at gmail.com> wrote: > You

Even after all the sequence of commands below bit-code is not showing any effect of loop-unrolling *manish at manish:~/Test2$ llvm-gcc-4.2 -O2 -emit-llvm Hello.c -c -o Hello.bc* *manish at manish:~/Test2$ opt-2.8 -loops Hello.bc -o Hello1.bc* *manish at manish:~/Test2$ opt-2.8 -loopsimplify Hello1.bc -o Hello2.bc* *manish at manish:~/Test2$ opt-2.8 -indvars Hello2.bc -o Hello3.bc* *manish at

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 =

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

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 ;

Sergey, Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". (Note that this patch won't ever be part of llvm-gcc upstream. It will most likely be deprecated by later changes.) - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110220/f814866f/attachment.html>

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: