[LLVMdev] LLVMdev Digest, Vol 55, Issue 16
Manoel Teixeira
manoel at fonetica.com.br
Thu Jan 8 02:19:46 PST 2009
1. Re: LLVM optmization (Bill Wendling)
Hi,
The IR is not wrong. I said that the assembler generated by MSVC is quicker. We can see that the for loop, in the TESTE function, is done without jump's in the MSVC and with jumps in LLVM. I think thats the point.
If we don't use threads, the result is the same. My test were done with one billion interactions in the for loop. The MSVC spent 47 miliseconds and the LLVM version 32 seconds.
Thanks,
Manoel Teixeira
Wed, 07 Jan 2009 15:35:59 -0600, llvmdev-request at cs.uiuc.edu escreveu:
> Send LLVMdev mailing list submissions to
> llvmdev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> or, via email, send a message with subject or body 'help' to
> llvmdev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> llvmdev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LLVMdev digest..."
>
>
> Today's Topics:
>
> 1. Re: LLVM optmization (Bill Wendling)
> 2. Re: opt pass plugins on Windows? (Martin Tofall)
> 3. Re: Private headers and testing (Misha Brukman)
> 4. Re: Private headers and testing (Chris Lattner)
> 5. Re: LLVM DebugInfoBuilder (Chris Lattner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 7 Jan 2009 11:40:02 -0800
> From: "Bill Wendling" <isanbard at gmail.com>
> Subject: Re: [LLVMdev] LLVM optmization
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Message-ID:
> <16e5fdf90901071140y3db1a899o9906828b0058303c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Wed, Jan 7, 2009 at 2:56 AM, Manoel Teixeira <manoel at fonetica.com.br> wrote:
> >
> > The following C test program was compiled using LLVM with -O3 option and MSVC with /O2.
> > The MSVC one is about 600 times faster than the one compiled with the LLVM.
> > We can see that the for loop in MSVC assembler is solved in the optimization pass more efficiently than that in LLVM.
> > Is there an way to get a optimization result in LLVM like that of the MSVC?
> > Manoel Teixeira
> >
> > #include <windows.h>
> > #include <stdio.h>
> >
> > int TESTE ( int parami ,int paraml ,double paramd )
> > {
> > int varx=0,vary=0;
> > int nI =0;
> >
> > if( parami > 0 )
> > {
> > varx = parami;
> > vary = 0;
> > }
> > else
> > {
> > varx = 0;
> > vary = paraml;
> > }
> > for( nI = 1 ; nI <= paraml; nI++)
> > {
> > varx = varx + parami + 1 ;
> > vary = varx + nI;
> > }
> >
> > return varx ;
> > }
> > unsigned long thread_call( LPVOID c )
> > {
> > int num = 1;
> > int (*fp)(int, int, double) = (int (*)(int, int,double)) c;
> > //printf("\n(1)threadid = %ld seqt=%ld inum=%d",GetCurrentThreadId(),num,inum);
> > int ret = fp(num,1000000000,1);
> > printf("\n(2)leu %ld threadid = %ld seqt=%ld ",ret , GetCurrentThreadId(),num);
> > return (unsigned long) ret;
> > }
> > ///cronometro
> > unsigned long tini;
> > unsigned long tfim;
> > #define getmilisecs(x) (x)
> > #define num_th 100
> > unsigned long milisecs() { return getmilisecs(tfim-tini);};
> > unsigned long secs() { return milisecs()/1000;};
> > const char *spenttime ()
> > {
> > static char buffer[64];
> > unsigned long systime = secs();
> > unsigned long milisectime = milisecs()%1000;
> > sprintf(buffer,"%02d:%02d:%02d:%03d",systime/3600,(systime%3600)/60,(systime%3600)%60,milisectime);
> > return (const char*) buffer;
> > };
> > //fim cronometro
> > int main(int a, char **b)
> > {
> > int i;
> > DWORD iThreadId;
> > HANDLE mainThread[num_th];
> > tfim = 0;
> > tini = GetTickCount();
>
> You're starting your count ...
>
> > for(i=0; i< num_th;i++)
> > mainThread[i] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thread_call, (LPVOID)TESTE, 0, (DWORD *)&iThreadId);
> >
> While doing a thread create method (which I don't have on my darwin
> box) that calls "printf". "printf" is I/O bound and makes for a lousy
> performance test.
>
> Nevertheless, I've attached the .s file generated by LLVM from the IR
> you gave. I can't see anything obviously wrong with it. Please point
> out in it which parts are 600x slower than on Windows. I'm not able to
> run it because I don't have a Windows box, and it requires some
> Windows calls.
>
> Note: The ASM is for a Darwin box. I didn't generate this code with
> frame pointers disabled. This would improve performance, but you
> didn't mention that you did the same for your Windows compile.
>
> -bw
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: y.s
> Type: application/octet-stream
> Size: 3984 bytes
> Desc: not available
> Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/2f929f53/attachment-0001.obj
>
> ------------------------------
>
> Message: 2
> Date: Wed, 7 Jan 2009 21:37:36 +0100
> From: Martin Tofall <obsidium at uni-paderborn.de>
> Subject: Re: [LLVMdev] opt pass plugins on Windows?
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <315912191.20090107213736 at uni-paderborn.de>
> Content-Type: text/plain; charset=iso-8859-15
>
> Hello,
>
> this is just a quick follow-up to my previous email. I now tried
> statically linking the 'hello' pass to opt which does seem to work.
> But I'm not sure if this is reliable or if I'm bound to run into
> problems later, so any comments on this issue would be appreciated.
>
> Martin
>
> Wednesday, January 7, 2009, 2:54:52 AM, you wrote:
>
> MT> Hello,
>
> MT> I'm just starting out with LLVM, currently using Visual Studio on
> MT> Windows. Now I'd like to write a custom pass that can be loaded
> MT> dynamically as demonstrated in the 'hello world' tutorial.
> MT> So far my DLL loads OK but the actual pass registration does not seem
> MT> to work.
> MT> My question then is (as I could not find any information on the
> MT> subject): is this even possible on win32 or will I have to move to a
> MT> different development platform?
>
> MT> Thanks,
> MT> Martin
>
> MT> _______________________________________________
> MT> LLVM Developers mailing list
> MT> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> MT> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 7 Jan 2009 16:29:09 -0500
> From: "Misha Brukman" <brukman at gmail.com>
> Subject: Re: [LLVMdev] Private headers and testing
> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> Message-ID:
> <f88b89a50901071329h2673c0c0t17853ca0bccfc01f at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 2009/1/3 Chris Lattner <clattner at apple.com>
>
> > On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
> >
> > 2009/1/2 Chris Lattner <clattner at apple.com>
> >
> >> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> >> Do you have a specific example of a unit test that would need these? I
> >> really think these should stay private.
> >>
> >
> > Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public interface
> > for it is in include/llvm/Transform/Utils/FunctionUtils.h, with only the
> > high-level API.
> >
> > If I want to test some corner-case (consider the number of code paths in
> > that code), I have to strain to come up with some combination of a Function
> > and input BasicBlocks that will fit all the conditions from the outset. Or,
> > I can just feed each individual method in the class exactly the corner cases
> > I will want it to handle, and verify its output (or side effects) exactly,
> > to make sure I pin-pointed the issue.
> >
> > Sure, ok. But that is a public API, I'm specifically interested in cases
> > you need private API.
> >
>
> I'm not sure I understand what you mean. What I am saying is that I want to
> expose the innards of CodeExtractor.cpp in a header file, #include that in
> the unittest, and move the implementation out of an anonymous namespace into
> llvm::transforms::utils, or llvm::internal::transforms::utils, or similar,
> so it can be unit-tested. This is not about exposing the private API to
> end-users of LLVM or even other LLVM libraries, just unittests.
>
> The public API, while useful to the end-user, is limiting when it comes to
> unit-testing. "Unit" in this case is a single method of the actual
> implementation (i.e., a method of the CodeExtractor class), not a single
> function call of the high-level exported public API, which will exercise the
> entire class and its many methods.
>
> Misha
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/f76ef1b4/attachment-0001.html
>
> ------------------------------
>
> Message: 4
> Date: Wed, 7 Jan 2009 13:33:40 -0800
> From: Chris Lattner <clattner at apple.com>
> Subject: Re: [LLVMdev] Private headers and testing
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <4BF5104C-E12E-4D2B-A72C-2AF35D939B83 at apple.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Jan 7, 2009, at 1:29 PM, Misha Brukman wrote:
>
> > 2009/1/3 Chris Lattner <clattner at apple.com>
> > On Jan 2, 2009, at 1:48 PM, Misha Brukman wrote:
> >> 2009/1/2 Chris Lattner <clattner at apple.com>
> >> On Jan 2, 2009, at 12:21 PM, Misha Brukman wrote:
> >> Do you have a specific example of a unit test that would need
> >> these? I really think these should stay private.
> >>
> >> Let's take lib/Transforms/Utils/CodeExtractor.cpp . The public
> >> interface for it is in include/llvm/Transform/Utils/
> >> FunctionUtils.h, with only the high-level API.
> >>
> >> If I want to test some corner-case (consider the number of code
> >> paths in that code), I have to strain to come up with some
> >> combination of a Function and input BasicBlocks that will fit all
> >> the conditions from the outset. Or, I can just feed each
> >> individual method in the class exactly the corner cases I will want
> >> it to handle, and verify its output (or side effects) exactly, to
> >> make sure I pin-pointed the issue.
> > Sure, ok. But that is a public API, I'm specifically interested in
> > cases you need private API.
> >
> > I'm not sure I understand what you mean. What I am saying is that I
> > want to expose the innards of CodeExtractor.cpp in a header file,
> > #include that in the unittest, and move the implementation out of an
> > anonymous namespace into llvm::transforms::utils, or
> > llvm::internal::transforms::utils, or similar, so it can be unit-
> > tested. This is not about exposing the private API to end-users of
> > LLVM or even other LLVM libraries, just unittests.
> >
> > The public API, while useful to the end-user, is limiting when it
> > comes to unit-testing. "Unit" in this case is a single method of
> > the actual implementation (i.e., a method of the CodeExtractor
> > class), not a single function call of the high-level exported public
> > API, which will exercise the entire class and its many methods.
>
> I am pretty strongly against that. Specifically for CodeExtractor,
> what benefit do you gain by doing this?
>
> -Chris
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20090107/5ca6e9a1/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Wed, 7 Jan 2009 13:35:50 -0800
> From: Chris Lattner <clattner at apple.com>
> Subject: Re: [LLVMdev] LLVM DebugInfoBuilder
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Message-ID: <0B93638D-EAB9-45F5-8C03-260213C56A8E at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote:
>
> > Hi list,
> > hi Talin,
> >
> > I'm working on a frontend to generate IR using the IRBuilder from
> > LLVM.
> >
> > Now I want to add source-level-debuginfo and for that I would like
> > to use the
> > DebugInfoBuilder as it is taking some of the burderns. Unfortunately
> > it does
> > not take all of them, yet.
>
> Instead of DebugInfoBuilder, I'd strongly recommend taking a look at
> include/llvm/Analysis/DebugInfo.h. This is the interface that llvm-
> gcc and clang both use to produce debug info. If it's ok with Talin,
> I'd like to eventually remove DebugInfoBuilder. Analysis/DebugInfo.h
> provides a nice and efficient API for both creating and reading debug
> info, and abstracts the clients from the actual form (e.g. serialized
> into GlobalVariables) that the debug info takes.
>
> -Chris
>
>
> ------------------------------
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> End of LLVMdev Digest, Vol 55, Issue 16
> ***************************************
>
>
>
>
More information about the llvm-dev
mailing list