From luoyonggang at gmail.com  Thu Oct  1 07:23:18 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Thu, 1 Oct 2009 20:23:18 +0800
Subject: [LLVMdev] A patch for LLVM cmake system that add new function to
	support for lost type detection function.
Message-ID: <806065d90910010523g21c3982el5e0fac4b133222ec@mail.gmail.com>

-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/be44334c/attachment.html 

From luoyonggang at gmail.com  Thu Oct  1 07:24:32 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Thu, 1 Oct 2009 20:24:32 +0800
Subject: [LLVMdev] A patch for LLVM cmake system that add new function to
	support for lost type detection function
Message-ID: <806065d90910010524x12281feake2fb811854159f5d@mail.gmail.com>

Hope it's will be working:)

-- 
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/497e6604/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-for-cmake-support-detect-types.patch
Type: application/octet-stream
Size: 3094 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/497e6604/attachment.obj 

From pijnacker at dse.nl  Thu Oct  1 06:22:37 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Thu, 1 Oct 2009 13:22:37 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
Message-ID: <20091001112237.GA25195@asus>

Hi all,

When I try to build llvm on windows/mingw32, I get the following error:

In file included from c:/work/mingw/src/llvm/lib/System/Signals.cpp:33:
c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc: In function 'LONG LLVMUnhandledExceptionFilter(_EXCEPTION_POINTERS*)':
c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc:275: error: exception handling disabled, use -fexceptions to enable
make[1]: *** [/c/work/mingw/src/build.llvm/lib/System/Release/Signals.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/c/work/mingw/src/build.llvm/lib/System'

Thanks,

Ronald

From dgregor at apple.com  Thu Oct  1 12:25:59 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Thu, 1 Oct 2009 10:25:59 -0700
Subject: [LLVMdev] A patch for LLVM cmake system that add new function
	to support for lost type detection function
In-Reply-To: <806065d90910010524x12281feake2fb811854159f5d@mail.gmail.com>
References: <806065d90910010524x12281feake2fb811854159f5d@mail.gmail.com>
Message-ID: <4A712C77-DE97-4CA4-AC66-B77426CB4549@apple.com>


On Oct 1, 2009, at 5:24 AM, ???(Yonggang Luo) wrote:

> Hope it's will be working:)

Looks good, thanks! I made a few cosmetic changes and committed it here:

	http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088224.html

	- Doug

From luoyonggang at gmail.com  Thu Oct  1 15:41:18 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Fri, 2 Oct 2009 04:41:18 +0800
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <20091001112237.GA25195@asus>
References: <20091001112237.GA25195@asus>
Message-ID: <806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>

Wow, I also meet this error before, I'll be pleasure if anyone can
solve this problem, and by the way, are you using msys as the building
env? It's seems that mingw/cmake is working but mingw/msys, and I
didn't ever try with mingw/cygwin:) thanks.

2009/10/1, Ronald Pijnacker <pijnacker at dse.nl>:
> Hi all,
>
> When I try to build llvm on windows/mingw32, I get the following error:
>
> In file included from c:/work/mingw/src/llvm/lib/System/Signals.cpp:33:
> c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc: In function 'LONG
> LLVMUnhandledExceptionFilter(_EXCEPTION_POINTERS*)':
> c:/work/mingw/src/llvm/lib/System/Win32/Signals.inc:275: error: exception
> handling disabled, use -fexceptions to enable
> make[1]: *** [/c/work/mingw/src/build.llvm/lib/System/Release/Signals.o]
> Error 1
> make[1]: *** Waiting for unfinished jobs....
> make[1]: Leaving directory `/c/work/mingw/src/build.llvm/lib/System'
>
> Thanks,
>
> Ronald
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From rengolin at systemcall.org  Thu Oct  1 16:35:51 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 1 Oct 2009 22:35:51 +0100
Subject: [LLVMdev] PHI and Allocas
Message-ID: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>

Hi,

I'm incrementing my toy compiler to account for variable mutations
around if/else blocks.

Reading the Kaleidoscope tutorial, I've learnt that I can substitute
the PHI node creation by allocas and retrieving the value later, if
needed. The Kaleidoscope example seems to account for one value only,
the result of:

Value *ThenV = Then->Codegen();
(...)
Value *ElseV = Else->Codegen();
(...)
PN->addIncoming(ThenV, ThenBB);
PN->addIncoming(ElseV, ElseBB);

But both Then and Else are expressions, so the Value returned is in
the form of a single variable.

ExprAST *Then = ParseExpression();
(...)
ExprAST *Else = ParseExpression();

In my toy language, I accept any number of statements inside a block.

Ignoring nested if statements, should I keep track of *each* variable
mutation inside the block, or is there some LLVM magic (as I'm getting
used to)?

A simple C example would be:

int a, b, c, d;
(...)
if (a > 10) {
  b = c = d = 10 * a;
} else {
  b = c = d = 10 / a;
}

As I'm always using alloca, the mem2reg pass seems to do the trick,
but I'm not sure it would in all cases. The tutorial states that it
works on all scalar values (I have no structs or arrays), so I believe
I'm safe.

Am I?

cheers,
--renato

From kennethuil at gmail.com  Thu Oct  1 16:41:34 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Thu, 1 Oct 2009 16:41:34 -0500
Subject: [LLVMdev] PHI and Allocas
In-Reply-To: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
References: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
Message-ID: <400d33ea0910011441i3d7998f4y87d77bef71be010@mail.gmail.com>

On Thu, Oct 1, 2009 at 4:35 PM, Renato Golin <rengolin at systemcall.org> wrote:
> Hi,
>
> I'm incrementing my toy compiler to account for variable mutations
> around if/else blocks.
>
> Reading the Kaleidoscope tutorial, I've learnt that I can substitute
> the PHI node creation by allocas and retrieving the value later, if
> needed. The Kaleidoscope example seems to account for one value only,
> the result of:
>
> Value *ThenV = Then->Codegen();
> (...)
> Value *ElseV = Else->Codegen();
> (...)
> PN->addIncoming(ThenV, ThenBB);
> PN->addIncoming(ElseV, ElseBB);
>
> But both Then and Else are expressions, so the Value returned is in
> the form of a single variable.
>
> ExprAST *Then = ParseExpression();
> (...)
> ExprAST *Else = ParseExpression();
>
> In my toy language, I accept any number of statements inside a block.
>
> Ignoring nested if statements, should I keep track of *each* variable
> mutation inside the block, or is there some LLVM magic (as I'm getting
> used to)?
>
> A simple C example would be:
>
> int a, b, c, d;
> (...)
> if (a > 10) {
> ?b = c = d = 10 * a;
> } else {
> ?b = c = d = 10 / a;
> }
>
> As I'm always using alloca, the mem2reg pass seems to do the trick,
> but I'm not sure it would in all cases. The tutorial states that it
> works on all scalar values (I have no structs or arrays), so I believe
> I'm safe.
>
> Am I?

I hope so, because I've been doing the same thing.  My local variables
are always bound to alloca's, and my test makefile just calls "opt
-std-compile-opts" after my compiler runs; so far it's been giving me
pretty good code as a result.


From rengolin at systemcall.org  Thu Oct  1 16:48:13 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Thu, 1 Oct 2009 22:48:13 +0100
Subject: [LLVMdev] PHI and Allocas
In-Reply-To: <400d33ea0910011441i3d7998f4y87d77bef71be010@mail.gmail.com>
References: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
	<400d33ea0910011441i3d7998f4y87d77bef71be010@mail.gmail.com>
Message-ID: <d9b9d95f0910011448g68796f24tf89e5a0559e9d537@mail.gmail.com>

2009/10/1 Kenneth Uildriks <kennethuil at gmail.com>:
> I hope so, because I've been doing the same thing. ?My local variables
> are always bound to alloca's, and my test makefile just calls "opt
> -std-compile-opts" after my compiler runs; so far it's been giving me
> pretty good code as a result.

Same here, but I'm not compiling any really complex code, so I thought
it was just beginner's luck.

Looks like it's another score for the "LLVM magic"! ;)

It might create problems for a potential debugger, but I'm not
planning to create one too soon.

cheers,
--renato


From kennethuil at gmail.com  Thu Oct  1 17:55:19 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Thu, 1 Oct 2009 17:55:19 -0500
Subject: [LLVMdev] PHI and Allocas
In-Reply-To: <d9b9d95f0910011448g68796f24tf89e5a0559e9d537@mail.gmail.com>
References: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
	<400d33ea0910011441i3d7998f4y87d77bef71be010@mail.gmail.com>
	<d9b9d95f0910011448g68796f24tf89e5a0559e9d537@mail.gmail.com>
Message-ID: <400d33ea0910011555v83c0425v750be879c5322a57@mail.gmail.com>

On Thu, Oct 1, 2009 at 4:48 PM, Renato Golin <rengolin at systemcall.org> wrote:
> 2009/10/1 Kenneth Uildriks <kennethuil at gmail.com>:
>> I hope so, because I've been doing the same thing. ?My local variables
>> are always bound to alloca's, and my test makefile just calls "opt
>> -std-compile-opts" after my compiler runs; so far it's been giving me
>> pretty good code as a result.
>
> Same here, but I'm not compiling any really complex code, so I thought
> it was just beginner's luck.
>
> Looks like it's another score for the "LLVM magic"! ;)
>
> It might create problems for a potential debugger, but I'm not
> planning to create one too soon.

There's a lot more magic where that came from.

Case in point:  my language has an "exit" statement, where any
statement you put after it gets run at the end of the scope it appears
in.  You can also put return statements in any scope you like, and
every containing scope will have its exit functions run on the way
out.  To make that work, I alloca'd a "destination scope" variable,
then when I finish a scope, I go to the exit statements, and the exit
statements are followed by a conditional jump based on the value of
the destination scope... I can go to the code right after the scope,
or to the containing scope's exit code.  A return statement just
compiles down to:

returnval = whatever
destScope = -1
goto scopeExit

If execution just goes to the end of the scope, it does:

destScope--;
goto scopeExit

Anyway, the code that my front-end outputs is full of statements
fiddling with scope destinations and conditional jumps, but when you
run it through "opt -std-compile-opts", all that goes away and, when
control unconditionally leaves a scope normally, the conditional
branches are gone too.


From luoyonggang at gmail.com  Thu Oct  1 18:07:43 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Fri, 2 Oct 2009 07:07:43 +0800
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
Message-ID: <806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>

Well, Now I get the solution.
Please, someone can apply the patch.

Just modify the makefile resident in lib/System

But, a new error is appeared
llvm[2]: Linking Debug unit test ADT
d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
undefined reference to `GetProcessMemoryInfo at 12'
collect2: ld returned 1 exit status
make[2]: *** [Debug/ADTTests.exe] Error 1
make[2]: Leaving directory `/d/objs/llvm/msys/unittests/ADT'
make[1]: *** [ADT/.makeall] Error 2
make[1]: Leaving directory `/d/objs/llvm/msys/unittests'
make: *** [all] Error 1


I don't know why, And Pijnacker, do you get the same error?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091002/04cc4be6/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: path-for-msys.patch
Type: application/octet-stream
Size: 316 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091002/04cc4be6/attachment.obj 

From criswell at uiuc.edu  Thu Oct  1 19:48:57 2009
From: criswell at uiuc.edu (John Criswell)
Date: Thu, 01 Oct 2009 18:48:57 -0600
Subject: [LLVMdev] Web Server Restart
Message-ID: <4AC54DF9.8090401@uiuc.edu>

Dear All,

I will be restarting the LLVM web server at 5:00 pacific time (7 pm 
Central time).  I need to turn on includes for one of the virtual hosts.

-- John T.


From criswell at uiuc.edu  Thu Oct  1 19:52:57 2009
From: criswell at uiuc.edu (John Criswell)
Date: Thu, 01 Oct 2009 18:52:57 -0600
Subject: [LLVMdev] Web Server Restart
In-Reply-To: <4AC54DF9.8090401@uiuc.edu>
References: <4AC54DF9.8090401@uiuc.edu>
Message-ID: <4AC54EE9.9070009@uiuc.edu>

John Criswell wrote:
> Dear All,
>
> I will be restarting the LLVM web server at 5:00 pacific time (7 pm 
> Central time).  I need to turn on includes for one of the virtual hosts.
>   
Please remember that the LLVM SVN server is part of the web servers, so 
please don't commit files until I let you know that the web server is 
back up.

-- John T.

> -- John T.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From criswell at uiuc.edu  Thu Oct  1 20:03:21 2009
From: criswell at uiuc.edu (John Criswell)
Date: Thu, 01 Oct 2009 19:03:21 -0600
Subject: [LLVMdev] Web Server Restart
In-Reply-To: <4AC54EE9.9070009@uiuc.edu>
References: <4AC54DF9.8090401@uiuc.edu> <4AC54EE9.9070009@uiuc.edu>
Message-ID: <4AC55159.6060803@uiuc.edu>

John Criswell wrote:
> John Criswell wrote:
>   
>> Dear All,
>>
>> I will be restarting the LLVM web server at 5:00 pacific time (7 pm 
>> Central time).  I need to turn on includes for one of the virtual hosts.
>>   
>>     
> Please remember that the LLVM SVN server is part of the web servers, so 
> please don't commit files until I let you know that the web server is 
> back up.
>   
The server is back up.  Please email if you notice if something is broken.

-- John T.

> -- John T.
>
>   
>> -- John T.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>   
>>     
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From ofv at wanadoo.es  Thu Oct  1 20:30:21 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Fri, 02 Oct 2009 03:30:21 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
Message-ID: <87y6nud1le.fsf@telefonica.net>

"???(Yonggang Luo)"  <luoyonggang at gmail.com> writes:

> Well, Now I get the solution.
> Please, someone can apply the patch.
>
> Just modify the makefile resident in lib/System

I'm afraid this patch is not acceptable. It activates C++ exception
support unconditionally while building libLLVMSystem, which is used
everywhere.

You'll better investigate why exception support is required for MSYS
while all other configure-based builds work fine without it.

[snip]

-- 
?scar


From dnmh68 at hotmail.com  Thu Oct  1 20:58:23 2009
From: dnmh68 at hotmail.com (dan mihai)
Date: Fri, 2 Oct 2009 01:58:23 +0000
Subject: [LLVMdev] alias analysis and functions
Message-ID: <BLU139-W4056292CE3CD095915501CED20@phx.gbl>


Hi,

I am trying to use alias analysis (Anderson) and noticed that for pointers to functions 
I don't get the expected result: a pointer that clearly may point to a function is 
reported as NoAlias.

I use -anders-aa  -aa-eval -print-no-aliases -print-may-aliases  -print-must-aliases

Here is a test case:

///////////////try_calls_aliases.c 
#include <stdio.h>

typedef int (*PF)();

PF pf01=0;
PF pf2=0;

int pointed_to_function0() {
  printf("pointed_to_function0\n");
  return 1;
}

int pointed_to_function1() {
  pf01 = pointed_to_function1;
  printf("pointed_to_function1\n");
  return 1;
}

void ptr_function_caller(PF pf) {
  printf("ptr_function_caller\n");
  pf();
  PF lpf0 = pointed_to_function0;
  PF lpf1 = pointed_to_function1;
}

int main(int argc, char* argv[]) {
  ptr_function_caller(pointed_to_function0);
  return 0;
}
-------------

After
 llvmgcc  -emit-llvm try_calls_aliases.c  -c -o try_calls_aliases.bc
 opt 2>&1   -anders-aa  -aa-eval -print-no-aliases -print-may-aliases  -print-must-aliases try_calls_aliases.bc | egrep -e 'Alias|Function' > c
I get:
...........
Function: ptr_function_caller: 8 pointers, 2 call sites
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*)
  NoAlias:    i32 (...)* %pf, i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*) ???????????????????????????????????????????????????????????????????????????????
  NoAlias:    i32 (...)* %pf, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*)
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)* %pf, i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i32 (...)** %pf_addr
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)** %pf_addr
  NoAlias:    i32 (...)* %pf, i32 (...)** %pf_addr
  NoAlias:    i32 (...)** %pf_addr, i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i32 (...)** %lpf1
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)** %lpf1
  NoAlias:    i32 (...)* %pf, i32 (...)** %lpf1
  NoAlias:    i32 (...)** %lpf1, i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)** %lpf1, i32 (...)** %pf_addr
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*), i32 (...)** %lpf0
  NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*), i32 (...)** %lpf0
  NoAlias:    i32 (...)* %pf, i32 (...)** %lpf0
  NoAlias:    i32 (...)** %lpf0, i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)** %lpf0, i32 (...)** %pf_addr
  NoAlias:    i32 (...)** %lpf0, i32 (...)** %lpf1
  NoAlias:    i32 (...)* %1, i32 (...)* bitcast (i32 ()* @pointed_to_function0 to i32 (...)*)
  NoAlias:    i32 (...)* %1, i32 (...)* bitcast (i32 ()* @pointed_to_function1 to i32 (...)*)
  MayAlias:    i32 (...)* %1, i32 (...)* %pf
  NoAlias:    i32 (...)* %1, i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
  NoAlias:    i32 (...)* %1, i32 (...)** %pf_addr
  NoAlias:    i32 (...)* %1, i32 (...)** %lpf1
  NoAlias:    i32 (...)* %1, i32 (...)** %lpf0
...............

Any advice on how to get this work as expected? (that is pf MayAlias pointed_to_function0 inside ptr_function_caller, etc)?

Thank you,
Dan


 		 	   		  
_________________________________________________________________
Insert movie times and more without leaving Hotmail?.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091002/8b25c086/attachment.html 

From eli.friedman at gmail.com  Thu Oct  1 22:15:08 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 1 Oct 2009 20:15:08 -0700
Subject: [LLVMdev] PHI and Allocas
In-Reply-To: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
References: <d9b9d95f0910011435m62794562r23ae5182a958b9d3@mail.gmail.com>
Message-ID: <f5aa3e9b0910012015h28183b6dj4b167a481e328864@mail.gmail.com>

On Thu, Oct 1, 2009 at 2:35 PM, Renato Golin <rengolin at systemcall.org> wrote:
> As I'm always using alloca, the mem2reg pass seems to do the trick,
> but I'm not sure it would in all cases. The tutorial states that it
> works on all scalar values (I have no structs or arrays), so I believe
> I'm safe.
>
> Am I?

Yes, you're safe; if the alloca is a scalar and you don't do anything
other than load and store to the alloca, mem2reg will eliminate the
alloca regardless of the control flow.  It's a fundamental property of
the algorithm to convert to SSA form; there's a comment in the source
code pointing to the paper in question if you're interested in the
theory.

-Eli

From viridia at gmail.com  Thu Oct  1 22:34:34 2009
From: viridia at gmail.com (Talin)
Date: Thu, 1 Oct 2009 20:34:34 -0700
Subject: [LLVMdev] DebugFactory
In-Reply-To: <352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>
References: <4AB87938.6080807@gmail.com>
	<352a1fb20909220921h7577d473v90c9c61c05de61ca@mail.gmail.com>
	<352a1fb20909220921w5c61511am5712e49a3a3b6cfa@mail.gmail.com>
	<d1b71f830909221649l4e2233c1h215d88529ea8ee2c@mail.gmail.com>
	<58C4E46A-95EC-40E2-9E1F-4E9E09C8B699@apple.com>
	<d1b71f830909231427r51de6aeek53d4aa78abcd7122@mail.gmail.com>
	<352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>
Message-ID: <d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>

Here is a patch that does just that.

On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote:

> On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote:
> > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote:
> >>
> >> On Sep 22, 2009, at 4:49 PM, Talin wrote:
> >>>
> >>> // Calculate the size of the specified LLVM type.
> >>> Constant * DebugInfoBuilder::getSize(const Type * type) {
> >>>    Constant * one = ConstantInt::get(Type::Int32Ty, 1);
> >>>    return ConstantExpr::getPtrToInt(
> >>>        ConstantExpr::getGetElementPtr(
> >>>            ConstantPointerNull::get(PointerType::getUnqual(type)),
> >>>            &one, 1), Type::Int32Ty);
> >>> }
> >>>
> >>> Constant * DebugInfoBuilder::getAlignment(const Type * type) {
> >>>    // Calculates the alignment of T using "sizeof({i8, T}) - sizeof(T)"
> >>>    return ConstantExpr::getSub(
> >>>        getSize(StructType::get(Type::Int8Ty, type, NULL)),
> >>>        getSize(type));
> >>> }
> >>
> >> Are ConstantExpr::getAlignOf, getSizeOf, and getOffsetOf what
> >> you're looking for?
> >>
> > That will work. Now all I need is for the methods of DIFactory to take a
> > Constant* instead of uint64.
>
> ok. Feel free to add
>    /// CreateBasicType - Create a basic type like int, float, etc.
>    DIBasicType CreateBasicType(DIDescriptor Context, const std::string
> &Name,
>                                DICompileUnit CompileUnit, unsigned
> LineNumber,
>                                uint64_t SizeInBits, uint64_t AlignInBits,
>                                uint64_t OffsetInBits, unsigned Flags,
>                                unsigned Encoding);
>
> variants that take Constant*, for example,
>
>    /// CreateBasicType - Create a basic type like int, float, etc.
>    DIBasicType CreateBasicType(DIDescriptor Context, const std::string
> &Name,
>                                DICompileUnit CompileUnit, unsigned
> LineNumber,
>                                Constant *SizeInBits, Constant *AlignInBits,
>                                Constant *OffsetInBits, unsigned Flags,
>                                unsigned Encoding);
>
> and so on.
> -
> Devang
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/b01836fa/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug_constants.patch
Type: application/octet-stream
Size: 7711 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/b01836fa/attachment.obj 

From alvin.cheung at gmail.com  Thu Oct  1 22:38:19 2009
From: alvin.cheung at gmail.com (Alvin Cheung)
Date: Thu, 01 Oct 2009 23:38:19 -0400
Subject: [LLVMdev] typedef struct
Message-ID: <4AC575AB.8010801@gmail.com>

Hi all,

If I have a C struct declaration like this:

typedef struct typeA {...} typeB;

In the type symbol table generated should it contain an entry for struct.typeA 
or struct.typeB?  I seem to have seen both cases using the same llvm toolchain 
so I just wonder if I have done something wrong.

Thanks,
Alvin

From clattner at apple.com  Thu Oct  1 22:51:37 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 1 Oct 2009 20:51:37 -0700
Subject: [LLVMdev] alias analysis and functions
In-Reply-To: <BLU139-W4056292CE3CD095915501CED20@phx.gbl>
References: <BLU139-W4056292CE3CD095915501CED20@phx.gbl>
Message-ID: <AD0C961A-B754-4325-99F8-F8E2927CFDFC@apple.com>


On Oct 1, 2009, at 6:58 PM, dan mihai wrote:

> Hi,
>
> I am trying to use alias analysis (Anderson) and noticed that for  
> pointers to functions
> I don't get the expected result: a pointer that clearly may point to  
> a function is
> reported as NoAlias.

Hi Dan,

Andersaa is extremely experimental at this point and has many known  
bugs.

-Chris

>
> I use -anders-aa  -aa-eval -print-no-aliases -print-may-aliases  - 
> print-must-aliases
>
> Here is a test case:
>
> ///////////////try_calls_aliases.c
> #include <stdio.h>
>
> typedef int (*PF)();
>
> PF pf01=0;
> PF pf2=0;
>
> int pointed_to_function0() {
>   printf("pointed_to_function0\n");
>   return 1;
> }
>
> int pointed_to_function1() {
>   pf01 = pointed_to_function1;
>   printf("pointed_to_function1\n");
>   return 1;
> }
>
> void ptr_function_caller(PF pf) {
>   printf("ptr_function_caller\n");
>   pf();
>   PF lpf0 = pointed_to_function0;
>   PF lpf1 = pointed_to_function1;
> }
>
> int main(int argc, char* argv[]) {
>   ptr_function_caller(pointed_to_function0);
>   return 0;
> }
> -------------
>
> After
>  llvmgcc  -emit-llvm try_calls_aliases.c  -c -o try_calls_aliases.bc
>  opt 2>&1   -anders-aa  -aa-eval -print-no-aliases -print-may- 
> aliases  -print-must-aliases try_calls_aliases.bc | egrep -e 'Alias| 
> Function' > c
> I get:
> ...........
> Function: ptr_function_caller: 8 pointers, 2 call sites
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to  
> i32 (...)*), i32 (...)* bitcast (i32 ()* @pointed_to_function1 to  
> i32 (...)*)
>   NoAlias:    i32 (...)* %pf, i32 (...)* bitcast (i32 ()*  
> @pointed_to_function0 to i32 (...) 
> *) ???????????????????????????????????????????????????????????????????????????????
>   NoAlias:    i32 (...)* %pf, i32 (...)* bitcast (i32 ()*  
> @pointed_to_function1 to i32 (...)*)
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to  
> i32 (...)*), i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to  
> i32 (...)*), i8* getelementptr ([20 x i8]* @.str2, i32 0, i64 0)
>   NoAlias:    i32 (...)* %pf, i8* getelementptr ([20 x i8]* @.str2,  
> i32 0, i64 0)
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to  
> i32 (...)*), i32 (...)** %pf_addr
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to  
> i32 (...)*), i32 (...)** %pf_addr
>   NoAlias:    i32 (...)* %pf, i32 (...)** %pf_addr
>   NoAlias:    i32 (...)** %pf_addr, i8* getelementptr ([20 x i8]*  
> @.str2, i32 0, i64 0)
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to  
> i32 (...)*), i32 (...)** %lpf1
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to  
> i32 (...)*), i32 (...)** %lpf1
>   NoAlias:    i32 (...)* %pf, i32 (...)** %lpf1
>   NoAlias:    i32 (...)** %lpf1, i8* getelementptr ([20 x i8]*  
> @.str2, i32 0, i64 0)
>   NoAlias:    i32 (...)** %lpf1, i32 (...)** %pf_addr
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function0 to  
> i32 (...)*), i32 (...)** %lpf0
>   NoAlias:    i32 (...)* bitcast (i32 ()* @pointed_to_function1 to  
> i32 (...)*), i32 (...)** %lpf0
>   NoAlias:    i32 (...)* %pf, i32 (...)** %lpf0
>   NoAlias:    i32 (...)** %lpf0, i8* getelementptr ([20 x i8]*  
> @.str2, i32 0, i64 0)
>   NoAlias:    i32 (...)** %lpf0, i32 (...)** %pf_addr
>   NoAlias:    i32 (...)** %lpf0, i32 (...)** %lpf1
>   NoAlias:    i32 (...)* %1, i32 (...)* bitcast (i32 ()*  
> @pointed_to_function0 to i32 (...)*)
>   NoAlias:    i32 (...)* %1, i32 (...)* bitcast (i32 ()*  
> @pointed_to_function1 to i32 (...)*)
>   MayAlias:    i32 (...)* %1, i32 (...)* %pf
>   NoAlias:    i32 (...)* %1, i8* getelementptr ([20 x i8]* @.str2,  
> i32 0, i64 0)
>   NoAlias:    i32 (...)* %1, i32 (...)** %pf_addr
>   NoAlias:    i32 (...)* %1, i32 (...)** %lpf1
>   NoAlias:    i32 (...)* %1, i32 (...)** %lpf0
> ...............
>
> Any advice on how to get this work as expected? (that is pf MayAlias  
> pointed_to_function0 inside ptr_function_caller, etc)?
>
> Thank you,
> Dan
>
>
>
> Insert movie times and more without leaving Hotmail?. See  
> how._______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091001/fc329237/attachment.html 

From davidterei at gmail.com  Thu Oct  1 23:05:22 2009
From: davidterei at gmail.com (David Terei)
Date: Fri, 2 Oct 2009 14:05:22 +1000
Subject: [LLVMdev] global constant next to function in generated binary
Message-ID: <150b8f420910012105q1ec31af6x4f1f320d8f401465@mail.gmail.com>

Hi all,

I was wondering if it is somehow possible to get llvm to generate code
such that you can enforce a relationship where a global constant and a
function are adjacent to each other in the binary. I want to do this
as its an optimisation technique used by the compiler I'm working on
(ghc). The global constant is a so called 'info table' which stores
information about the function needed by the run time system. The
unoptimised layout is to have the info table store a pointer to the
code it is tied to but this increases the size of the info table and
also requires two indirect jumps to get to the code. Having the table
and code adjacent as in the optimised layout allows access to both
through just one pointer using the correct offsets, reducing the info
table and number of indirect jumps required to access the function.

If this isn't possible currently in LLVM where would llvm need to be
changed to implement this and would this be something the llvm devs
would be happy to accept patches for?

Cheers,
David

From luoyonggang at gmail.com  Thu Oct  1 23:41:36 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Fri, 2 Oct 2009 12:41:36 +0800
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <87y6nud1le.fsf@telefonica.net>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com> 
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com> 
	<87y6nud1le.fsf@telefonica.net>
Message-ID: <806065d90910012141k7d24644cvf7b315c38b58ef81@mail.gmail.com>

>
>
> I'm afraid this patch is not acceptable. It activates C++ exception
> support unconditionally while building libLLVMSystem, which is used
> everywhere.
>
> You'll better investigate why exception support is required for MSYS
> while all other configure-based builds work fine without it.
>
> Sorry, I got no idea to solve this problem, do you have a method to get it
done?
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091002/653f4787/attachment.html 

From jay.foad at gmail.com  Fri Oct  2 06:01:49 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Fri, 2 Oct 2009 12:01:49 +0100
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <87y6nud1le.fsf@telefonica.net>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<87y6nud1le.fsf@telefonica.net>
Message-ID: <ee2e06e90910020401q15dd967bqbf03b4f5ae9b3028@mail.gmail.com>

> You'll better investigate why exception support is required for MSYS
> while all other configure-based builds work fine without it.

Surely it's required for any system that uses
lib/System/Win32/Signals.inc, because there's code in that file that
uses try/catch.

MingW is the only system I know of that uses that file; Cygwin
pretends to be Unix-like, so it uses lib/System/Unix/Signals.inc
instead. So I'd suggest the attached (untested) patch.

Jay.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libsystem.patch
Type: application/octet-stream
Size: 342 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091002/b196319e/attachment.obj 

From pijnacker at dse.nl  Fri Oct  2 04:44:00 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Fri, 2 Oct 2009 11:44:00 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
Message-ID: <20091002094400.GB10459@asus>

> Well, Now I get the solution.
> Please, someone can apply the patch.
> 
> Just modify the makefile resident in lib/System
> 
> But, a new error is appeared
> llvm[2]: Linking Debug unit test ADT
> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> undefined reference to `GetProcessMemoryInfo at 12'
> collect2: ld returned 1 exit status
> make[2]: *** [Debug/ADTTests.exe] Error 1
> make[2]: Leaving directory `/d/objs/llvm/msys/unittests/ADT'
> make[1]: *** [ADT/.makeall] Error 2
> make[1]: Leaving directory `/d/objs/llvm/msys/unittests'
> make: *** [all] Error 1
> 
> 
> I don't know why, And Pijnacker, do you get the same error?

Yes, I get the same error.

Ronald


From dimitry at andric.com  Fri Oct  2 09:08:05 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri, 02 Oct 2009 16:08:05 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
References: <20091001112237.GA25195@asus>	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
Message-ID: <4AC60945.6060802@andric.com>

On 2009-10-02 01:07, ???(Yonggang Luo)  wrote:
> Well, Now I get the solution.
> Please, someone can apply the patch.
> 
> Just modify the makefile resident in lib/System
> 
> But, a new error is appeared
> llvm[2]: Linking Debug unit test ADT
> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> undefined reference to `GetProcessMemoryInfo at 12'

GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
doesn't have this import lib.  It is included in the MS Platform SDK,
but I'm not sure whether you can link that into mingw32 programs...



From pijnacker at dse.nl  Fri Oct  2 12:34:05 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Fri, 2 Oct 2009 19:34:05 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <4AC60945.6060802@andric.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com>
Message-ID: <20091002173405.GA16433@asus>

> On 2009-10-02 01:07, ???(Yonggang Luo)  wrote:
> > Well, Now I get the solution.
> > Please, someone can apply the patch.
> > 
> > Just modify the makefile resident in lib/System
> > 
> > But, a new error is appeared
> > llvm[2]: Linking Debug unit test ADT
> > d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> > undefined reference to `GetProcessMemoryInfo at 12'
> 
> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> doesn't have this import lib.  It is included in the MS Platform SDK,
> but I'm not sure whether you can link that into mingw32 programs...
 
msdn suggests kernel32, but that is already included.

Ronald

From dimitry at andric.com  Fri Oct  2 13:25:27 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri, 02 Oct 2009 20:25:27 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <ee2e06e90910020401q15dd967bqbf03b4f5ae9b3028@mail.gmail.com>
References: <20091001112237.GA25195@asus>	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>	<87y6nud1le.fsf@telefonica.net>
	<ee2e06e90910020401q15dd967bqbf03b4f5ae9b3028@mail.gmail.com>
Message-ID: <4AC64597.1010409@andric.com>

On 2009-10-02 13:01, Jay Foad wrote:
> Surely it's required for any system that uses
> lib/System/Win32/Signals.inc, because there's code in that file that
> uses try/catch.
> 
> MingW is the only system I know of that uses that file; Cygwin
> pretends to be Unix-like, so it uses lib/System/Unix/Signals.inc
> instead. So I'd suggest the attached (untested) patch.

It won't work as-is, because HOST_OS is not defined at that point in the
Makefile.  Including Makefile.config helps, at least in my case. :)

E.g:

Index: lib/System/Makefile
===================================================================
--- lib/System/Makefile	(revision 83249)
+++ lib/System/Makefile	(working copy)
@@ -11,6 +11,12 @@
 LIBRARYNAME = LLVMSystem
 BUILD_ARCHIVE = 1
 
+include $(LEVEL)/Makefile.config
+
+ifeq ($(HOST_OS),MingW)
+REQUIRES_EH := 1
+endif
+
 EXTRA_DIST = Unix Win32 README.txt
 
 include $(LEVEL)/Makefile.common

From dimitry at andric.com  Fri Oct  2 13:51:17 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri, 02 Oct 2009 20:51:17 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <20091002173405.GA16433@asus>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
Message-ID: <4AC64BA5.8010708@andric.com>

On 2009-10-02 19:34, Ronald Pijnacker wrote:
>> On 2009-10-02 01:07, ???(Yonggang Luo)  wrote:
>>> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
>>> undefined reference to `GetProcessMemoryInfo at 12'
>> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
>> doesn't have this import lib.  It is included in the MS Platform SDK,
>> but I'm not sure whether you can link that into mingw32 programs...
> msdn suggests kernel32, but that is already included.

My apologies, I was mistaken, as Yonggang pointed out to me privately;
mingw32 does come with a libpsapi.lib file, but in your case it does not
get added to the libs to be linked with, apparently.

In my case, the configure script does check for the existence of
libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
-lpsapi to LIBS.

Can you find anything in your config.log file about libpsapi?



From pijnacker at dse.nl  Fri Oct  2 13:59:56 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Fri, 2 Oct 2009 20:59:56 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <4AC64BA5.8010708@andric.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com>
Message-ID: <20091002185956.GA16922@asus>

> >>> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> >>> undefined reference to `GetProcessMemoryInfo at 12'
> >> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> >> doesn't have this import lib.  It is included in the MS Platform SDK,
> >> but I'm not sure whether you can link that into mingw32 programs...
> > msdn suggests kernel32, but that is already included.
> 
> My apologies, I was mistaken, as Yonggang pointed out to me privately;
> mingw32 does come with a libpsapi.lib file, but in your case it does not
> get added to the libs to be linked with, apparently.
> 
> In my case, the configure script does check for the existence of
> libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
> -lpsapi to LIBS.
> 
> Can you find anything in your config.log file about libpsapi?

#define HAVE_LIBPSAPI 1
  in config.h

Ronald

From pijnacker at dse.nl  Fri Oct  2 14:07:18 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Fri, 2 Oct 2009 21:07:18 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <20091002185956.GA16922@asus>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com> <20091002185956.GA16922@asus>
Message-ID: <20091002190718.GB16922@asus>

> > >>> d:/objs/llvm/msys/Debug/lib/libLLVMSystem.a(Process.o):e:/Downloads/llvm-trunk/lib/System/Win32/Process.inc:78:
> > >>> undefined reference to `GetProcessMemoryInfo at 12'
> > >> GetProcessMemoryInfo should be defined in psapi.lib, but AFAICS mingw32
> > >> doesn't have this import lib.  It is included in the MS Platform SDK,
> > >> but I'm not sure whether you can link that into mingw32 programs...
> > > msdn suggests kernel32, but that is already included.
> > 
> > My apologies, I was mistaken, as Yonggang pointed out to me privately;
> > mingw32 does come with a libpsapi.lib file, but in your case it does not
> > get added to the libs to be linked with, apparently.
> > 
> > In my case, the configure script does check for the existence of
> > libpsapi.a, and adds both a HAVE_LIBPSAPI define to config.h, and
> > -lpsapi to LIBS.
> > 
> > Can you find anything in your config.log file about libpsapi?
> 
> #define HAVE_LIBPSAPI 1
>   in config.h
 
I had a close look at the link line, and -lpsapi is specified before -lLLVMSystem (which is giving the error).
When I put -lpsapi after -lLLVMSystem, it links ok.

Ronald

From benny.kra at googlemail.com  Fri Oct  2 14:37:41 2009
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Fri, 2 Oct 2009 21:37:41 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <20091002190718.GB16922@asus>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com> <20091002185956.GA16922@asus>
	<20091002190718.GB16922@asus>
Message-ID: <CEAB1C45-01EB-4CAA-A2E1-EB838DD24F33@gmail.com>


Am 02.10.2009 um 21:07 schrieb Ronald Pijnacker:

> I had a close look at the link line, and -lpsapi is specified before  
> -lLLVMSystem (which is giving the error).
> When I put -lpsapi after -lLLVMSystem, it links ok.

I commited a fix for this problem and a modified version of Jay's  
patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088265.html

I hope MingW builds work again now :)

From dimitry at andric.com  Fri Oct  2 15:00:52 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri, 02 Oct 2009 22:00:52 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <CEAB1C45-01EB-4CAA-A2E1-EB838DD24F33@gmail.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com> <20091002185956.GA16922@asus>
	<20091002190718.GB16922@asus>
	<CEAB1C45-01EB-4CAA-A2E1-EB838DD24F33@gmail.com>
Message-ID: <4AC65BF4.6090107@andric.com>

On 2009-10-02 21:37, Benjamin Kramer wrote:
>> I had a close look at the link line, and -lpsapi is specified before  
>> -lLLVMSystem (which is giving the error).
>> When I put -lpsapi after -lLLVMSystem, it links ok.
> 
> I commited a fix for this problem and a modified version of Jay's  
> patch here:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090928/088265.html
> 
> I hope MingW builds work again now :)

Now the problem comes from another side, as GNU ld seems rather picky
about the library order:

$ g++ -I/d/Home/Dim/Src/llvm/include -I/d/Home/Dim/Src/llvm/obj/include -I/d/Home/Dim/Src/llvm/obj/unittests/Transforms/Utils -I/d/Home/Dim/Src/llvm/unittests/Transforms/Utils  -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -I/d/Home/Dim/Src/llvm/utils/unittest/googletest/include/ -Wno-variadic-macros -g -fno-exceptions -Woverloaded-virtual      -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -g -L/d/Home/Dim/Src/llvm/obj/Debug/lib -L/d/Home/Dim/Src/llvm/obj/Debug/lib  -o Debug/UtilsTests.exe  /d/Home/Dim/Src/llvm/obj/unittests/Transforms/Utils/Debug/Cloning.o -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem   -lpthread -lpsapi -limagehlp -lm  -lGoogleTest -lUnitTestMain
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm14raw_os_ostreamC1ERSo[llvm::raw_os_ostream::raw_os_ostream(std::basic_ostre
am<char, std::char_traits<char> >&)]+0x1e): undefined reference to `vtable for llvm::raw_os_ostream'
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm23convertible_fwd_ostreamD1Ev[llvm::convertible_fwd_ostream::~convertible_fw
d_ostream()]+0x2b): undefined reference to `llvm::raw_os_ostream::~raw_os_ostream()'
d:/Home/Dim/Src/llvm/obj/Debug/lib/libGoogleTest.a(gtest.o):gtest.cc:(.text$_ZN4llvm23convertible_fwd_ostreamD0Ev[llvm::convertible_fwd_ostream::~convertible_fw
d_ostream()]+0x2b): undefined reference to `llvm::raw_os_ostream::~raw_os_ostream()'
collect2: ld returned 1 exit status

E.g. now libGoogletest.a requires some symbols from libLLVMSupport.a,
and it has been moved to the end of the linking command line.

When I make the order:

-lGoogleTest
-lUnitTestMain
-lLLVMTransformUtils
-lLLVMipa
-lLLVMAnalysis
-lLLVMTarget
-lLLVMMC
-lLLVMCore
-lLLVMSupport
-lLLVMSystem  
-lpthread
-lpsapi
-limagehlp
-lm 

it links okay.  I have tested a similar fix as r83252, which I saw you
just committed, and that seems to work.  At least, it's far into the
examples directory by now, without problems...


From dimitry at andric.com  Fri Oct  2 15:08:34 2009
From: dimitry at andric.com (Dimitry Andric)
Date: Fri, 02 Oct 2009 22:08:34 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <4AC65BF4.6090107@andric.com>
References: <20091001112237.GA25195@asus>
	<806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com> <20091002185956.GA16922@asus>
	<20091002190718.GB16922@asus>
	<CEAB1C45-01EB-4CAA-A2E1-EB838DD24F33@gmail.com>
	<4AC65BF4.6090107@andric.com>
Message-ID: <4AC65DC2.4080007@andric.com>

On 2009-10-02 22:00, Dimitry Andric wrote:
> it links okay.  I have tested a similar fix as r83252, which I saw you
> just committed, and that seems to work.  At least, it's far into the
> examples directory by now, without problems...

Apologies for replying to myself, but I just want to confirm that it now
(with r83252) builds completely to the end.  Thanks for the quick fix.

From ransford at cs.umass.edu  Fri Oct  2 15:11:27 2009
From: ransford at cs.umass.edu (Ben Ransford)
Date: Fri, 2 Oct 2009 16:11:27 -0400
Subject: [LLVMdev] Mailing list for out-of-band MSP430 backend discussion
Message-ID: <b7e7fde10910021311x5d653650p575ad11fbbd74cdf@mail.gmail.com>

Hello,

Several people have expressed interest in using LLVM to target MSP430
microcontrollers.  Anton wrote an MSP430 backend as an exercise, and
some of the nastiest parts are done (thanks Anton!), but the consensus
seems to be that there's still quite a bit of work left to do before
LLVM can replace the commercial and open-source compilers (IAR, CCE,
CrossWorks, mspgcc, and so on) that people use.

I've created a mailing list where we can have graphic, detailed
discussions of the MSP430 and its LLVM backend.  Feel free to
subscribe for discussion and/or lurking.

  http://lists.ransford.org/mailman/listinfo/llvm-msp430

We'll try to redirect questions to llvmdev if they aren't MSP430 specific.

-ben

From pijnacker at dse.nl  Fri Oct  2 17:30:01 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Sat, 3 Oct 2009 00:30:01 +0200
Subject: [LLVMdev] llvm build errors on windows/mingw32
In-Reply-To: <4AC65DC2.4080007@andric.com>
References: <806065d90910011341g56fc5d2dh4403fc9a5ada8ee9@mail.gmail.com>
	<806065d90910011607y41ce1980qfc791e357c0fbfb5@mail.gmail.com>
	<4AC60945.6060802@andric.com> <20091002173405.GA16433@asus>
	<4AC64BA5.8010708@andric.com> <20091002185956.GA16922@asus>
	<20091002190718.GB16922@asus>
	<CEAB1C45-01EB-4CAA-A2E1-EB838DD24F33@gmail.com>
	<4AC65BF4.6090107@andric.com> <4AC65DC2.4080007@andric.com>
Message-ID: <20091002223001.GA18056@asus>

> On 2009-10-02 22:00, Dimitry Andric wrote:
> > it links okay.  I have tested a similar fix as r83252, which I saw you
> > just committed, and that seems to work.  At least, it's far into the
> > examples directory by now, without problems...
> 
> Apologies for replying to myself, but I just want to confirm that it now
> (with r83252) builds completely to the end.  Thanks for the quick fix.
> 

Thanks. Indeed it builds ok now.

Ronald

From pijnacker at dse.nl  Fri Oct  2 17:32:35 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Sat, 3 Oct 2009 00:32:35 +0200
Subject: [LLVMdev] Cannot find crt2.o with llvm-gcc on windows/mingw
Message-ID: <20091002223235.GB18056@asus>

Hi all,

After being able to build llvm and llvm-gcc on windows/mingw,
I am running into problems with linking.
It seems llvm-gcc isn't able to find crt2.o.

Ronald

From viridia at gmail.com  Sat Oct  3 00:16:01 2009
From: viridia at gmail.com (Talin)
Date: Fri, 02 Oct 2009 22:16:01 -0700
Subject: [LLVMdev] Internalize pass
In-Reply-To: <63C7823F-ACAD-4704-ABB9-4990967C4C0E@apple.com>
References: <d1b71f830909300006vb50e012r15b08610acc0a6d3@mail.gmail.com>
	<63C7823F-ACAD-4704-ABB9-4990967C4C0E@apple.com>
Message-ID: <4AC6DE11.4090309@gmail.com>

Well, after some investigation I have a few more clues as to what is 
going on.

I have a module which contains a call to an external native function. 
This native function lives in a static library, and there is an external 
declaration for it in the module.

I find that I can run "llvm-ld -disable-opts -native -l mylibrary 
test.bc" and it works fine. That is, llvm-ld is able to generate a 
native object file, and link it against the static library with no problem.

However, if I remove the "-disable-opts" line, it seems to replace the 
call to the native function with "unreachable". I'm not 100% certain of 
this, but if I replace the native function with a non-native function 
that does something similar, then it seems to work ok.

Chris Lattner wrote:
>
> On Sep 30, 2009, at 12:06 AM, Talin wrote:
>
>> I'm playing around with different combinations of LTO passes, and 
>> I've run into a strange problem:
>>
>> I have a 'main' function that looks like this:
>>
>> define i32 
>> @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* 
>> %args) {
>> entry:
>>   call void @llvm.dbg.func.start(metadata !0)
>>   call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata !1)
>>   %integerLimitsTest = call { } @integerLimitsTest() ; <{ }> [#uses=0]
>>   call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>   %integerToStringTest = call { } @integerToStringTest() ; <{ }> 
>> [#uses=0]
>>   call void @llvm.dbg.stoppoint(i32 4, i32 9, metadata !1)
>>   call void @llvm.dbg.region.end(metadata !0)
>>   ret i32 0
>> }
>>
>> However, when I add an internalize pass before the other LTO passes, 
>> the 'main' function turns into this:
>>
>> define i32 @main(i32, i8** nocapture) nounwind readnone {
>> entry:
>>   tail call void @llvm.dbg.func.start(metadata !0)
>>   tail call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>   unreachable
>> }
>>
>> The thing is, there's nothing particularly special or interesting 
>> about the functions being called from main().
>
> This is likely to not be due to internalize itself.  Internalize marks 
> functions "internal", which allows other interprocedural optimizers to 
> have more freedom to change their interfaces etc.  The likely problem 
> here is that you are calling something from 'main' with mismatching 
> calling conventions or something like that.  It is hard to say without 
> a full testcase.
>
> -Chris


From viridia at gmail.com  Sat Oct  3 00:38:24 2009
From: viridia at gmail.com (Talin)
Date: Fri, 02 Oct 2009 22:38:24 -0700
Subject: [LLVMdev] More on dwarf debugging
Message-ID: <4AC6E350.8040005@gmail.com>

I've been working on getting my front end to generate the proper 
source-level debugging intrinsics, and I have a couple of observations:

1) I've never actually been able to get gdb to recognize my debug data. 
I've tried the various -O0 and disabling frame pointer elimination, and 
when I look at the assembly it seems OK, but gdb just won't recognize 
it. I've even tried downloading a more recent version of gdb, but 
unfortunately the latest official gdb release won't configure under OS 
X, and when I tried checking out the branch head it wouldn't compile.

2) It's very hard to determine whether or not the generated debug 
information is correct. One reason is that the way that debug 
information is encoded in LL files is essentially unreadable. I can look 
at a typical IR file and puzzle out what the code is supposed to be 
doing, but there's no easy way to look at the metadata and verify that 
it is correct.

What I would like to see is either (a) a way to encode debugging 
information in the module that is slightly easier on the eyes, or (b) 
some sort of pretty-printer utility that would take in a module and 
print a summary of the debug info for a given symbol.

-- Talin


From luoyonggang at gmail.com  Sat Oct  3 03:14:31 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 3 Oct 2009 16:14:31 +0800
Subject: [LLVMdev] [cfe-dev] Cross-compiling with clang
In-Reply-To: <5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
References: <31014a580910022014p7dda3b8eyf80b051468fea77c@mail.gmail.com>
	<5BF49EAE-035B-48D6-9488-F71981D09477@apple.com>
Message-ID: <806065d90910030114l217e4bb0pe447930911e1007a@mail.gmail.com>

Indeed, I am very interested in this area, because of the frustrating
feleling of using gcc about cross compiling. Even though I don't have
much time, but I can submit some idea about this field;)

2009/10/3, Chris Lattner <clattner at apple.com>:
> On Oct 2, 2009, at 8:14 PM, Mark A. Miller wrote:
>> As a preface, I am not a compiler developer, so please take my
>> questions with a grain of salt. But there doesn't appear to be a
>> clang-user mailing list, so I'm posting to -dev.
>>
>> I'm extremely interested in clang, since it both attempts to be
>> saner than what gcc has become, and doesn't have the community
>> forking licensing issues of GPLv2 and GPLv3. My recent projects have
>> involved building cross-compilers for various targets, such as ARM,
>> MIPS, PPC, sh4, et cetera.
>>
>> My main question is, has any work been done on allowing clang to
>> cross-compile various targets? I found the following bug:
>> http://llvm.org/bugs/show_bug.cgi?id=4127
>>  which indicated that it was still a work in progress.
>>
>> Also, I suppose this question may be better posed to the llvm list,
>> but is there any documentation on how to use a gcc frontend and llvm
>> backend to cross-compile?
>>
>> Lastly, and this is more of a slight nitpick issue, since I managed
>> to find the bug with the following mailing list post:
>> http://article.gmane.org/gmane.comp.compilers.clang.devel/5893
>>  I'd point out that the -arch feature currently only works on
>> MacOSX. I wasted several hours trying to figure out what I was doing
>> wrong on my Linux installation until I found ths out.
>
> Hi Mark,
>
> This is an area that we are actively interested in involving, but no
> one is driving yet.  Are you interested in helping out?  I'm not too
> familiar with the issues and Daniel (who is most knowledgeable about
> the driver) is out on vacation for 2 weeks.
>
> -Chris

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From baldrick at free.fr  Sat Oct  3 09:27:14 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 03 Oct 2009 16:27:14 +0200
Subject: [LLVMdev] A patch for LLVM cmake system that add new function
 to	support for lost type detection function.
In-Reply-To: <806065d90910010523g21c3982el5e0fac4b133222ec@mail.gmail.com>
References: <806065d90910010523g21c3982el5e0fac4b133222ec@mail.gmail.com>
Message-ID: <4AC75F42.6040207@free.fr>

Looks like you forgot to attach the patch.

Ciao,

Duncan.

From luoyonggang at gmail.com  Sat Oct  3 09:39:45 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Sat, 3 Oct 2009 22:39:45 +0800
Subject: [LLVMdev] A patch for LLVM cmake system that add new function
	to support for lost type detection function.
In-Reply-To: <4AC75F42.6040207@free.fr>
References: <806065d90910010523g21c3982el5e0fac4b133222ec@mail.gmail.com>
	<4AC75F42.6040207@free.fr>
Message-ID: <806065d90910030739s71c0b6bdoc088f9be071e631b@mail.gmail.com>

Sorry, that patch has already been applied;) sorry for that:(

2009/10/3, Duncan Sands <baldrick at free.fr>:
> Looks like you forgot to attach the patch.
>
> Ciao,
>
> Duncan.
>

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From baldrick at free.fr  Sat Oct  3 09:56:55 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sat, 03 Oct 2009 16:56:55 +0200
Subject: [LLVMdev] typedef struct
In-Reply-To: <4AC575AB.8010801@gmail.com>
References: <4AC575AB.8010801@gmail.com>
Message-ID: <4AC76637.8020202@free.fr>

Hi Alvin,

> If I have a C struct declaration like this:
> 
> typedef struct typeA {...} typeB;
> 
> In the type symbol table generated should it contain an entry for struct.typeA 
> or struct.typeB?  I seem to have seen both cases using the same llvm toolchain 
> so I just wonder if I have done something wrong.

it doesn't matter what the name is since it has no effect on generated
code.  It's only in debug info that type names matter, so if you are not
seeing this in debug info I wouldn't worry about it if I were you.

Ciao,

Duncan.

From rnk at mit.edu  Sat Oct  3 12:47:23 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Sat, 3 Oct 2009 13:47:23 -0400
Subject: [LLVMdev] Internalize pass
In-Reply-To: <4AC6DE11.4090309@gmail.com>
References: <d1b71f830909300006vb50e012r15b08610acc0a6d3@mail.gmail.com> 
	<63C7823F-ACAD-4704-ABB9-4990967C4C0E@apple.com>
	<4AC6DE11.4090309@gmail.com>
Message-ID: <9a9942200910031047v682230e7oadf27713b53b326d@mail.gmail.com>

Sounds like LLVM thinks the calling conventions or declarations are
mismatched.  See:
http://llvm.org/docs/FAQ.html#callconvwrong

Reid

On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote:
> Well, after some investigation I have a few more clues as to what is
> going on.
>
> I have a module which contains a call to an external native function.
> This native function lives in a static library, and there is an external
> declaration for it in the module.
>
> I find that I can run "llvm-ld -disable-opts -native -l mylibrary
> test.bc" and it works fine. That is, llvm-ld is able to generate a
> native object file, and link it against the static library with no problem.
>
> However, if I remove the "-disable-opts" line, it seems to replace the
> call to the native function with "unreachable". I'm not 100% certain of
> this, but if I replace the native function with a non-native function
> that does something similar, then it seems to work ok.
>
> Chris Lattner wrote:
>>
>> On Sep 30, 2009, at 12:06 AM, Talin wrote:
>>
>>> I'm playing around with different combinations of LTO passes, and
>>> I've run into a strange problem:
>>>
>>> I have a 'main' function that looks like this:
>>>
>>> define i32
>>> @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*
>>> %args) {
>>> entry:
>>> ? call void @llvm.dbg.func.start(metadata !0)
>>> ? call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata !1)
>>> ? %integerLimitsTest = call { } @integerLimitsTest() ; <{ }> [#uses=0]
>>> ? call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>> ? %integerToStringTest = call { } @integerToStringTest() ; <{ }>
>>> [#uses=0]
>>> ? call void @llvm.dbg.stoppoint(i32 4, i32 9, metadata !1)
>>> ? call void @llvm.dbg.region.end(metadata !0)
>>> ? ret i32 0
>>> }
>>>
>>> However, when I add an internalize pass before the other LTO passes,
>>> the 'main' function turns into this:
>>>
>>> define i32 @main(i32, i8** nocapture) nounwind readnone {
>>> entry:
>>> ? tail call void @llvm.dbg.func.start(metadata !0)
>>> ? tail call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>> ? unreachable
>>> }
>>>
>>> The thing is, there's nothing particularly special or interesting
>>> about the functions being called from main().
>>
>> This is likely to not be due to internalize itself. ?Internalize marks
>> functions "internal", which allows other interprocedural optimizers to
>> have more freedom to change their interfaces etc. ?The likely problem
>> here is that you are calling something from 'main' with mismatching
>> calling conventions or something like that. ?It is hard to say without
>> a full testcase.
>>
>> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From remy.demarest at gmail.com  Sat Oct  3 07:04:11 2009
From: remy.demarest at gmail.com (Remy Demarest)
Date: Sat, 3 Oct 2009 14:04:11 +0200
Subject: [LLVMdev] LLVM-Kaleidoscope tutorial
Message-ID: <9F9B8F7E-054A-45BA-A521-3BC2CD410282@gmail.com>

Good morning everyone,

It seems the LLVM tutorial is not up to date anymore and doesn't  
compile as is...

The function makeLLVMModule() function doesn't compile at all. Here is  
a fix:

Module *makeLLVMModule()
{
     // Caches the global context to share it with new Module() and  
IntegerType::get() calls
     LLVMContext &context = getGlobalContext();

     // Module Construction
     Module *mod = new Module("test", context);

     Constant *c = mod->getOrInsertFunction("mul_add",
                                            // IntegerType::get 
(context, 32) instead of IntegerType::get(32)
                                            IntegerType::get(context,  
32), // Return type
                                            IntegerType::get(context,  
32), // Arguments
                                            IntegerType::get(context,  
32),
                                            IntegerType::get(context,  
32),
                                             
NULL                           // Varargs terminated with NULL
                                            );

     Function* mul_add = cast<Function>(c);
     mul_add->setCallingConv(CallingConv::C);
     Function::arg_iterator args = mul_add->arg_begin();
     Value *x = args++;
     x->setName("x");
     Value *y = args++;
     y->setName("y");
     Value *z = args++;
     z->setName("z");
     BasicBlock *block = BasicBlock::Create(getGlobalContext(),  
"entry", mul_add);
     IRBuilder<> builder(block);
     Value *tmp = builder.CreateBinOp(Instruction::Mul,
                                      x, y, "tmp");
     Value *tmp2 = builder.CreateBinOp(Instruction::Add,
                                       tmp, z, "tmp2");

     builder.CreateRet(tmp2);

     return mod;
}

__________________________
Remy Demarest
remy.demarest at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091003/045f77c9/attachment.html 

From espiritusantu at mail.ru  Sat Oct  3 13:45:16 2009
From: espiritusantu at mail.ru (dilas dilas)
Date: Sat, 03 Oct 2009 22:45:16 +0400
Subject: [LLVMdev] Compilation of library
Message-ID: <E1Mu9bY-0003dJ-00.espiritusantu-mail-ru@f260.mail.ru>

How to compile the libstdc++ library to LLVM bitcode?

From rengolin at systemcall.org  Sat Oct  3 15:40:44 2009
From: rengolin at systemcall.org (Renato Golin)
Date: Sat, 3 Oct 2009 21:40:44 +0100
Subject: [LLVMdev] LLVM-Kaleidoscope tutorial
In-Reply-To: <9F9B8F7E-054A-45BA-A521-3BC2CD410282@gmail.com>
References: <9F9B8F7E-054A-45BA-A521-3BC2CD410282@gmail.com>
Message-ID: <d9b9d95f0910031340m785075cen40eec38756a8c129@mail.gmail.com>

2009/10/3 Remy Demarest <remy.demarest at gmail.com>:
> Good morning everyone,
> It seems the LLVM tutorial is not up to date anymore and doesn't compile as
> is...
> The function makeLLVMModule() function doesn't compile at all. Here is a

The Kaleidoscope in the source tree is correct, but the web page is
not updated as often. Lots has changed since and you should use the
source on:

llvm/examples/Kaleidoscope

which compiles to:

llvm/Debug/examples

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

From daniel.wilkerson at gmail.com  Sat Oct  3 17:06:23 2009
From: daniel.wilkerson at gmail.com (Daniel Wilkerson)
Date: Sat, 3 Oct 2009 15:06:23 -0700
Subject: [LLVMdev] code generation goes into an infinite loop
Message-ID: <48f102b60910031506g581c0491i9b483dd7547fd715@mail.gmail.com>

We seem to be creating an infinite loop in llvm while trying to
implement the simplest possible code generation.  Specifically, we are
trying to emit code for the following program, as it is easily
testable from the command-line:

    int main(int argc) { return argc; }

We got our code generator to build and link with llvm.  When we run
it, it pauses when running the PrintModulePass and then exits with a
bus error.  I suspect that this is an infinite loop leading to a stack
overflow.

While many kinds of errors we could fix by looking at other people's
examples or reading the docs, I suspect that this should be considered
to be a bug in the verifier pass: clearly we generated wrong LLVM
datastructures somehow and the verifier is not catching it before the
emitter falls off a cliff.  Please comment.

Daniel

// modified from:
  // llvm/docs/tutorial/JITTutorial1.html

  // make an LLVM module
  printf("%s:%d make module\n", __FILE__, __LINE__);
//   Module* Mod = makeLLVMModule();
  llvm::Module *mod = new llvm::Module("test");

  // make a function object
  printf("%s:%d make function\n", __FILE__, __LINE__);
//   Constant* c = mod->getOrInsertFunction
//     ("mul_add",
//      /*ret type*/ IntegerType::get(32),
//      /*args*/ IntegerType::get(32),
//      IntegerType::get(32),
//      IntegerType::get(32),
//      /*varargs terminated with null*/ NULL);
  llvm::Constant *c = mod->getOrInsertFunction
    ("main",                    // function name
     llvm::IntegerType::get(32), // return type
     llvm::IntegerType::get(32), // one argument (argc)
     NULL                       // terminate list of varargs
     );
  llvm::Function *main_function = llvm::cast<llvm::Function>(c);
  main_function->setCallingConv(llvm::CallingConv::C);

  // make the body of the function
  printf("%s:%d make body\n", __FILE__, __LINE__);
  llvm::Function::arg_iterator args = main_function->arg_begin();
  llvm::Value* arg1 = args++;
  arg1->setName("argc");

  printf("%s:%d make block\n", __FILE__, __LINE__);
  llvm::BasicBlock *block = llvm::BasicBlock::Create("entry", main_function);
  llvm::IRBuilder<> builder(block);
  builder.CreateRet(arg1);

  // verify the module
  printf("%s:%d verify\n", __FILE__, __LINE__);
  verifyModule(*mod, llvm::PrintMessageAction);

  // render the module
  printf("%s:%d render\n", __FILE__, __LINE__);
  llvm::PassManager PM;
  llvm::ModulePass *pmp = llvm::createPrintModulePass(0); // (&llvm::cout);
  PM.add(pmp);
  PM.run(*mod);

  // delete the module
  printf("%s:%d delete module\n", __FILE__, __LINE__);
  delete mod;

From peter at pcc.me.uk  Sun Oct  4 00:07:51 2009
From: peter at pcc.me.uk (Peter Collingbourne)
Date: Sat, 3 Oct 2009 22:07:51 -0700
Subject: [LLVMdev] [PATCH] problems building shared libraries with cmake
Message-ID: <20091004050751.GB1258@pcc.me.uk>

Hello,

I experienced link errors building on Linux with "cmake
-DBUILD_SHARED_LIBS=ON"; applying this patch solved the problem for me.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-cmake-so1.patch
Type: text/x-diff
Size: 844 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091003/26827705/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091003/26827705/attachment-0001.bin 

From ofv at wanadoo.es  Sun Oct  4 01:25:49 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sun, 04 Oct 2009 08:25:49 +0200
Subject: [LLVMdev] [PATCH] problems building shared libraries with cmake
References: <20091004050751.GB1258@pcc.me.uk>
Message-ID: <87my47d6aa.fsf@telefonica.net>

Peter Collingbourne <peter at pcc.me.uk> writes:

> I experienced link errors building on Linux with "cmake
> -DBUILD_SHARED_LIBS=ON"; applying this patch solved the problem for me.

Applied.

Thanks!

-- 
?scar


From alvin.cheung at gmail.com  Sun Oct  4 11:41:20 2009
From: alvin.cheung at gmail.com (Alvin Cheung)
Date: Sun, 04 Oct 2009 12:41:20 -0400
Subject: [LLVMdev] typedef struct
In-Reply-To: <4AC76637.8020202@free.fr>
References: <4AC575AB.8010801@gmail.com> <4AC76637.8020202@free.fr>
Message-ID: <4AC8D030.4020703@gmail.com>

Hi Duncan,

Actually what I am doing is matching up each Type with its corresponding debug 
info.  I have checked that the debug info generated is consistent (i.e., typeA 
is recorded as a derived type from composite type typeB in my example), but I 
have seen cases where the name recorded in the Type object is typeA and 
sometimes typeB, that's why I am confused.

Alvin

Duncan Sands wrote:
> Hi Alvin,
> 
>> If I have a C struct declaration like this:
>>
>> typedef struct typeA {...} typeB;
>>
>> In the type symbol table generated should it contain an entry for 
>> struct.typeA or struct.typeB?  I seem to have seen both cases using 
>> the same llvm toolchain so I just wonder if I have done something wrong.
> 
> it doesn't matter what the name is since it has no effect on generated
> code.  It's only in debug info that type names matter, so if you are not
> seeing this in debug info I wouldn't worry about it if I were you.
> 
> Ciao,
> 
> Duncan.

From baldrick at free.fr  Sun Oct  4 11:50:25 2009
From: baldrick at free.fr (Duncan Sands)
Date: Sun, 04 Oct 2009 18:50:25 +0200
Subject: [LLVMdev] typedef struct
In-Reply-To: <4AC8D030.4020703@gmail.com>
References: <4AC575AB.8010801@gmail.com> <4AC76637.8020202@free.fr>
	<4AC8D030.4020703@gmail.com>
Message-ID: <4AC8D251.40307@free.fr>

Hi Alvin,

> Actually what I am doing is matching up each Type with its corresponding 
> debug info.  I have checked that the debug info generated is consistent 
> (i.e., typeA is recorded as a derived type from composite type typeB in 
> my example), but I have seen cases where the name recorded in the Type 
> object is typeA and sometimes typeB, that's why I am confused.

do you get this naming strangeness in the debug info, or in other parts
of the LLVM IR?  LLVM uses structural equivalence, so for example two
struct types with the same fields are considered to be the same.  This
can result in the "wrong" name being used for the type in the IR.  So if
that's the phenomenon you are seeing then there is nothing wrong because
this is not visible to users.  However if the wrong name is being output
in debug info (so in gdb you would see the wrong name) then that sounds
like a bug.  So can you please be more clear about exactly when you see
this strangeness.

Ciao,

Duncan.

From daniel.wilkerson at gmail.com  Sun Oct  4 14:21:11 2009
From: daniel.wilkerson at gmail.com (Daniel Wilkerson)
Date: Sun, 4 Oct 2009 12:21:11 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
In-Reply-To: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
Message-ID: <48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>

Where exactly is this mythical Kaleidoscope example?  I have llvm 2.5 installed.

examples dsw$ ls
BrainF		Fibonacci	Makefile	ParallelJIT
CMakeLists.txt	HowToUseJIT	ModuleMaker

> Date: Sat, 3 Oct 2009 21:40:44 +0100
> From: Renato Golin <rengolin at systemcall.org>
> Subject: Re: [LLVMdev] LLVM-Kaleidoscope tutorial
>
> 2009/10/3 Remy Demarest <remy.demarest at gmail.com>:
>> Good morning everyone,
>> It seems the LLVM tutorial is not up to date anymore and doesn't compile as
>> is...
>> The function makeLLVMModule() function doesn't compile at all. Here is a
>
> The Kaleidoscope in the source tree is correct, but the web page is
> not updated as often. Lots has changed since and you should use the
> source on:
>
> llvm/examples/Kaleidoscope

From ofv at wanadoo.es  Sun Oct  4 14:34:37 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sun, 04 Oct 2009 21:34:37 +0200
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
	<48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
Message-ID: <87hbufc5rm.fsf@telefonica.net>

Daniel Wilkerson <daniel.wilkerson at gmail.com> writes:

> Where exactly is this mythical Kaleidoscope example?  I have llvm 2.5 installed.

It's on svn. Maybe in the 2.6 RC too.

-- 
?scar


From deeppatel1987 at gmail.com  Sun Oct  4 20:42:51 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Mon, 5 Oct 2009 01:42:51 +0000
Subject: [LLVMdev] getting gold plugin to work?
Message-ID: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>

Attached is the start of a patch to make the gold plugin work on
Darwin for use as a cross-compiler. There needs to be a build step
somewhere in llvm-gcc that copies it into libexec/<gcc
poop>/libLLVMgold.so, but I've been doing that manually for now.

It doesn't seem that simple use of -O4 results in the plugin learning
what subtarget is desired. I presume that the llvm-gcc driver needs to
pass -mcpu down through collect2 into ld somehow. Has anybody solved
this already? Perhaps we should finally just put the feature string
into the bitcode?

deep
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gold-plugin-darwin-cross.diff
Type: application/octet-stream
Size: 445 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091005/1f60368e/attachment.obj 

From clattner at apple.com  Sun Oct  4 21:27:24 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 4 Oct 2009 19:27:24 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
In-Reply-To: <48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
	<48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
Message-ID: <72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>


On Oct 4, 2009, at 12:21 PM, Daniel Wilkerson wrote:

> Where exactly is this mythical Kaleidoscope example?  I have llvm  
> 2.5 installed.

http://llvm.org/docs/tutorial/

-Chris

From daniel.wilkerson at gmail.com  Sun Oct  4 21:31:21 2009
From: daniel.wilkerson at gmail.com (Daniel Wilkerson)
Date: Sun, 4 Oct 2009 19:31:21 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
In-Reply-To: <72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
	<48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
	<72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>
Message-ID: <48f102b60910041931m7b124681h21eefd02bb55e9ca@mail.gmail.com>

That's not an example, that's a tutorial, and an incomplete one at
that.  However I did find the Kaleidoscope example in the subversion
repository head.

Any clue as to why when we attempt to follow the very simple example
in the llvm-2.5 release docs/tutorial/JITTutorial1.html we construct a
module state that verifies but then when we ask it to emit, we get a
stack overflow from LLVM?

Is it supposed to be possible for me to render out an LLVM
datastructure that will verify but not render?  That is, is this my
bug or an LLVM bug?

Daniel

On Sun, Oct 4, 2009 at 7:27 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 4, 2009, at 12:21 PM, Daniel Wilkerson wrote:
>
>> Where exactly is this mythical Kaleidoscope example? ?I have llvm 2.5
>> installed.
>
> http://llvm.org/docs/tutorial/
>
> -Chris
>


From clattner at apple.com  Sun Oct  4 21:39:00 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 4 Oct 2009 19:39:00 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
In-Reply-To: <48f102b60910041931m7b124681h21eefd02bb55e9ca@mail.gmail.com>
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>
	<48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
	<72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>
	<48f102b60910041931m7b124681h21eefd02bb55e9ca@mail.gmail.com>
Message-ID: <2046FDE2-6650-4847-A4B2-BB8D25382D66@apple.com>


On Oct 4, 2009, at 7:31 PM, Daniel Wilkerson wrote:

> That's not an example, that's a tutorial, and an incomplete one at
> that.  However I did find the Kaleidoscope example in the subversion
> repository head.
>
> Any clue as to why when we attempt to follow the very simple example
> in the llvm-2.5 release docs/tutorial/JITTutorial1.html we construct a
> module state that verifies but then when we ask it to emit, we get a
> stack overflow from LLVM?

The most likely reason is that you didn't follow the instructions, and  
are using a known-broken GCC:
http://llvm.org/docs/GettingStarted.html#brokengcc

or that you've found a new one.

-Chris

From nicholas at mxc.ca  Mon Oct  5 00:59:16 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 04 Oct 2009 22:59:16 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 5
In-Reply-To: <72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>
References: <mailman.1.1254675602.25252.llvmdev@cs.uiuc.edu>	<48f102b60910041221s2c73e928w294300861c315a36@mail.gmail.com>
	<72BC61FB-5FE7-4B77-85EA-1EBD30697E4A@apple.com>
Message-ID: <4AC98B34.2010003@mxc.ca>

Chris Lattner wrote:
> On Oct 4, 2009, at 12:21 PM, Daniel Wilkerson wrote:
> 
>> Where exactly is this mythical Kaleidoscope example?  I have llvm  
>> 2.5 installed.
> 
> http://llvm.org/docs/tutorial/

For llvm 2.5, that should be:

http://llvm.org/releases/2.5/docs/tutorial/

Nick

From Olaf.Krzikalla at tu-dresden.de  Mon Oct  5 03:45:06 2009
From: Olaf.Krzikalla at tu-dresden.de (Olaf Krzikalla)
Date: Mon, 05 Oct 2009 10:45:06 +0200
Subject: [LLVMdev] Source-to-Source transformations
In-Reply-To: <4AC1D2E6.3080705@inf.uth.gr>
References: <4AC1D2E6.3080705@inf.uth.gr>
Message-ID: <4AC9B212.4090706@tu-dresden.de>

Konstantis,

I'm writing a ASTProcessing lib with which you already could do a
transformation like yours in a hurry.
It is however not part of the clang project nor will it becomes one
since it depends on boost.
You should be able to check out the current stuff via anon SVN (look at
https://gforge.zih.tu-dresden.de/scm/?group_id=16).
The interesting part is trunk/Scout/clangAddons (the other folders on
the Scout level are trash).
Note that this is still work in heavy progress. Also I'm of course eager
to get your remarks or even submissions.
(e.g. StmtCollector::tStmtTreeMirror::compareOneLevel is still broken
(probably by design)).

Best regards
Olaf Krzikalla



From stephan.reiter at gmail.com  Mon Oct  5 09:21:23 2009
From: stephan.reiter at gmail.com (Stephan Reiter)
Date: Mon, 5 Oct 2009 16:21:23 +0200
Subject: [LLVMdev] Functions: sret and readnone
Message-ID: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>

Hi all,

I'm currently building a DSL for a computer graphics project that is
not unlike NVIDIA's Cg. I have an intrinsic with the following
signature

float4 sample(texture tex, float2 coords);

that is translated to this LLVM IR code:

declare void @"sample"(%float4* noalias nocapture sret, %texture,
$float2) nounwind readnone

The type float4 is basically an array of four floats, which cannot be
returned directly on an x86 using the traditional calling conventions
but only via the sret mechanism.

You might already have spotted that "readnone" attribute, which is
causing some problems: The GVN optimization pass seems to treat the
sret pointer just like any other pointer to memory and eliminates all
calls to the function, since it sees it as returning void without
touching any memory. Is there a way to make sure that the GVN pass
interpretes the sret argument as the actual return value of the
function? Or are there other approaches I could try?

Currently, the only way to make sure that the sample function behaves
as expected is to drop the "readnone" attribute, but that obviously
hinders optimization ...

Thanks a lot,
Stephan

From espindola at google.com  Mon Oct  5 09:21:31 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 5 Oct 2009 10:21:31 -0400
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
Message-ID: <38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>

2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>:
> Attached is the start of a patch to make the gold plugin work on
> Darwin for use as a cross-compiler.

Nice. I checked that it still builds correctly on linux. I think it is
fine, but Nick should probably have a look.

> There needs to be a build step
> somewhere in llvm-gcc that copies it into libexec/<gcc
> poop>/libLLVMgold.so, but I've been doing that manually for now.

Yes, this is bad. The problem is that we build the plugin in llvm, not
llvm-gcc. Another option is to add a new search directory to llvm-gcc.
That way you could configure llvm-gcc with a --gold-plugin-dir=<path>
and the resulting binary would search there. This would work nicely
when using an already installed llvm copy.

> It doesn't seem that simple use of -O4 results in the plugin learning
> what subtarget is desired. I presume that the llvm-gcc driver needs to
> pass -mcpu down through collect2 into ld somehow. Has anybody solved
> this already? Perhaps we should finally just put the feature string
> into the bitcode?

Interesting. It is probably better to pass it via the command line. I
will try to take a look at it. Do you have a small testcase?

> deep
>

Thanks,
-- 
Rafael ?vila de Esp?ndola


From kennethuil at gmail.com  Mon Oct  5 09:59:05 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 5 Oct 2009 09:59:05 -0500
Subject: [LLVMdev] Functions: sret and readnone
In-Reply-To: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
Message-ID: <400d33ea0910050759u1997754ai7df2cec4f62143f6@mail.gmail.com>

On Mon, Oct 5, 2009 at 9:21 AM, Stephan Reiter <stephan.reiter at gmail.com> wrote:
> Hi all,
>
> I'm currently building a DSL for a computer graphics project that is
> not unlike NVIDIA's Cg. I have an intrinsic with the following
> signature
>
> float4 sample(texture tex, float2 coords);
>
> that is translated to this LLVM IR code:
>
> declare void @"sample"(%float4* noalias nocapture sret, %texture,
> $float2) nounwind readnone
>
> The type float4 is basically an array of four floats, which cannot be
> returned directly on an x86 using the traditional calling conventions
> but only via the sret mechanism.
>
> You might already have spotted that "readnone" attribute, which is
> causing some problems: The GVN optimization pass seems to treat the
> sret pointer just like any other pointer to memory and eliminates all
> calls to the function, since it sees it as returning void without
> touching any memory. Is there a way to make sure that the GVN pass
> interpretes the sret argument as the actual return value of the
> function? Or are there other approaches I could try?
>
> Currently, the only way to make sure that the sample function behaves
> as expected is to drop the "readnone" attribute, but that obviously
> hinders optimization ...
>
> Thanks a lot,
> Stephan

I believe you are out of luck for the time being.

I plan to change the codegen stage so that it handles large struct
returns; then you could declare your function to return the four
floats directly and mark it readnone.  But I don't have a target date
for that change.

From criswell at cs.uiuc.edu  Mon Oct  5 10:21:24 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 5 Oct 2009 10:21:24 -0500
Subject: [LLVMdev] [Fwd: Re: problem with multiple LLVM passes]
In-Reply-To: <bf0e41fc0910041233o6b0bda96n2e107760078dd0dc@mail.gmail.com>
References: <4AAAA6C7.8080106@cs.uiuc.edu>
	<bf0e41fc0910041233o6b0bda96n2e107760078dd0dc@mail.gmail.com>
Message-ID: <4ACA0EF4.5070004@cs.uiuc.edu>

Rakesh Komuravelli wrote:
> Hi John,
>
> I am having the exact same problem. Let me answer the four questions
> that you have asked..
>
> 1) Are both passes included in the same dynamic library?  If not, are
> you loading their respective libraries with multiple -load options?
>
> Yes. I load both the libraries with two -load options. I see both the
> passes listed when run opt with --help flag
Okay.  This means that both passes are loading successfully.
>
> 2) Do both passes have a static <Passname>::ID variable defined in their
> respective .cpp files?
>
> Yes. I also tried initializing them with different values.
Just to be paranoid: each pass is using its own ID varibles, correct?

>
> 3) Is LiveVars an analysis pass?  Does it say that it preserves all
> other passes in its getAnalysisUsage() method?  If not, you could have a
> dependency chain that never gets resolved.
>
> I inserted AU.setPreservesAll() in getAnalysisUsage of the first pass
I assume the first pass is an analysis pass that call
AU.setPreservesAll(), and the second pass is a transform pass that
preserves nothing.  Is this correct?

>
> 4) Does opt print any error messages when loading the dynamic
> library/libraries implementing your two passes?
>
> opt prints the following error message:
>
> opt: /home/sadve/komurav1/llvm/include/llvm/PassAnalysisSupport.h:53:
> llvm::AnalysisUsage& llvm::AnalysisUsage::addRequiredID(const
> llvm::PassInfo*): Assertion `ID && "Pass class not registered!"' failed.
>
> Any insight on what might be going wrong?
So, my purpose in asking the above questions was to eliminate several
possible causes.  It looks like your passes are loading properly.  I am
assuming that each pass is using a separate ID variable, so that
shouldn't the problem either.

My only guess at this point is that it may be possible for there to be
an unsolvable dependency in your passes.  An example of this can occur
when a transform pass doubles as an analysis pass: if the transform pass
T invalidates an analysis pass A, and then another pass P requires both
T and A, the pass manager hits a similar assertion because it can't
schedule both T and A such that they are available simultaneously for
pass P.

A quick test to see if this is the problem is to make the transform pass
preserve all other passes and then try running both the analysis pass
and the transform pass.  If it works, then there's a scheduling
dependency problem.

I'm forwarding this email to llvmdev in hopes that someone else has
other ideas on how to debug this problem without diving into the pass
manager internals.  I can help you with that if necessary (I've done it
before), but I'd like to avoid it if possible.

-- John T.

> Thanks,
> Rakesh
>
> On Fri, Sep 11, 2009 at 2:36 PM, John Criswell <criswell at cs.uiuc.edu
> <mailto:criswell at cs.uiuc.edu>> wrote:
>
>     My reply button isn't working like it used to...
>     :)
>
>     -- John T.
>
>
>     Susan Horwitz wrote:
>     > I'm trying to write two LLVM passes, one of which uses the
>     results of the
>     > other.  The first is LiveVars and the second is RemoveUseless.
>      In the
>     > RemoveUseless class I have:
>     >
>     There's a number of things that could be going wrong.  Here are some
>     questions to try to narrow down what might be the problem:
>
>     1) Are both passes included in the same dynamic library?  If not, are
>     you loading their respective libraries with multiple -load options?
>
>     2) Do both passes have a static <Passname>::ID variable defined in
>     their
>     respective .cpp files?
>
>     3) Is LiveVars an analysis pass?  Does it say that it preserves all
>     other passes in its getAnalysisUsage() method?  If not, you could
>     have a
>     dependency chain that never gets resolved.
>
>     4) Does opt print any error messages when loading the dynamic
>     library/libraries implementing your two passes?
>
>     -- John T.
>
>     >    virtual void getAnalysisUsage(AnalysisUsage &AU) const {
>     >      AU.addRequired<LiveVars>();
>     >    }
>     >
>     > This compiles fine, but when I try to run it I get an error:
>     >        Pass class not registered!
>     >
>     > The error goes away if I take out that "addRequired".
>     >
>     > The code for the LiveVars pass includes
>     >       RegisterPass<LiveVars> X("liveVars", "Live vars analysis",
>     true,
>     >       true);
>     >
>     > and I can run the LiveVars pass like this:
>     >       opt -load Debug/lib/dataflowAnalysis.so -f -analyze
>     -liveVars ...
>     >
>     > I've tried running the RemoveUseless pass with various
>     combinations of flags
>     > (just -removeUseless, both -liveVars and -removeUseles, with and
>     without
>     > -analyze), but I always get the same error.
>     >
>     >
>     > Any help will be much appreciated!
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
>     http://llvm.cs.uiuc.edu
>     > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>     >
>
>
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From baldrick at free.fr  Mon Oct  5 10:23:55 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 05 Oct 2009 17:23:55 +0200
Subject: [LLVMdev] Functions: sret and readnone
In-Reply-To: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
Message-ID: <4ACA0F8B.5030707@free.fr>

Hi Stephan,

> You might already have spotted that "readnone" attribute, which is
> causing some problems: The GVN optimization pass seems to treat the
> sret pointer just like any other pointer to memory and eliminates all
> calls to the function, since it sees it as returning void without
> touching any memory.

as explained in the language reference,
  http://llvm.org/docs/LangRef.html,
readonly functions must not write to any byval arguments.
The reason for this is that it allows the inliner to avoid introducing
a temporary variable and copy when inlining readonly functions with
a byval argument.

Is there a way to make sure that the GVN pass
> interpretes the sret argument as the actual return value of the
> function? Or are there other approaches I could try?

Not for the moment, sorry.

Ciao,

Duncan.

From devang.patel at gmail.com  Mon Oct  5 11:24:31 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 5 Oct 2009 09:24:31 -0700
Subject: [LLVMdev] More on dwarf debugging
In-Reply-To: <4AC6E350.8040005@gmail.com>
References: <4AC6E350.8040005@gmail.com>
Message-ID: <352a1fb20910050924m3742dd16r34bb3ee8b18adb4f@mail.gmail.com>

On Fri, Oct 2, 2009 at 10:38 PM, Talin <viridia at gmail.com> wrote:
> I've been working on getting my front end to generate the proper
> source-level debugging intrinsics, and I have a couple of observations:
>
> 1) I've never actually been able to get gdb to recognize my debug data.
> I've tried the various -O0 and disabling frame pointer elimination, and
> when I look at the assembly it seems OK, but gdb just won't recognize
> it. I've even tried downloading a more recent version of gdb, but
> unfortunately the latest official gdb release won't configure under OS
> X, and when I tried checking out the branch head it wouldn't compile.
>
> 2) It's very hard to determine whether or not the generated debug
> information is correct. One reason is that the way that debug
> information is encoded in LL files is essentially unreadable. I can look
> at a typical IR file and puzzle out what the code is supposed to be
> doing, but there's no easy way to look at the metadata and verify that
> it is correct.
>
> What I would like to see is either (a) a way to encode debugging
> information in the module that is slightly easier on the eyes, or (b)
> some sort of pretty-printer utility that would take in a module and
> print a summary of the debug info for a given symbol.

(b) is the right choice here. A MDPrinter as part of AsmWriter to
pretty-print debug info is the way to go.

There is also a need for DwarfChecker. The goal here is to check
consistency of debug info encoded in LLVM IR and remove inconsistent
info. This is not same as traditional Verifier, which is readonly. The
debug info is optional and various passes are allowed to
discard/remove debug info that gets in their way.

-
Devang

From clattner at apple.com  Mon Oct  5 11:56:03 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 09:56:03 -0700
Subject: [LLVMdev] Functions: sret and readnone
In-Reply-To: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
Message-ID: <2472616D-80DB-4C27-A695-C9191E9E9C07@apple.com>


On Oct 5, 2009, at 7:21 AM, Stephan Reiter wrote:

> Hi all,
>
> I'm currently building a DSL for a computer graphics project that is
> not unlike NVIDIA's Cg. I have an intrinsic with the following
> signature
>
> float4 sample(texture tex, float2 coords);
>
> that is translated to this LLVM IR code:
>
> declare void @"sample"(%float4* noalias nocapture sret, %texture,
> $float2) nounwind readnone

The best thing to do to handle this is to add a custom AliasAnalysis  
implementation, which will know the precise mod/ref sets for the  
function.  See docs/AliasAnalysis.html for some more information.

-Chris

>
> The type float4 is basically an array of four floats, which cannot be
> returned directly on an x86 using the traditional calling conventions
> but only via the sret mechanism.
>
> You might already have spotted that "readnone" attribute, which is
> causing some problems: The GVN optimization pass seems to treat the
> sret pointer just like any other pointer to memory and eliminates all
> calls to the function, since it sees it as returning void without
> touching any memory. Is there a way to make sure that the GVN pass
> interpretes the sret argument as the actual return value of the
> function? Or are there other approaches I could try?
>
> Currently, the only way to make sure that the sample function behaves
> as expected is to drop the "readnone" attribute, but that obviously
> hinders optimization ...
>
> Thanks a lot,
> Stephan
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From daniel.wilkerson at gmail.com  Mon Oct  5 12:41:42 2009
From: daniel.wilkerson at gmail.com (Daniel Wilkerson)
Date: Mon, 5 Oct 2009 10:41:42 -0700
Subject: [LLVMdev] LLVMdev Digest, Vol 64, Issue 6
In-Reply-To: <mailman.5.1254762002.22355.llvmdev@cs.uiuc.edu>
References: <mailman.5.1254762002.22355.llvmdev@cs.uiuc.edu>
Message-ID: <48f102b60910051041o45ad59e7h2176a3b26257627c@mail.gmail.com>

I am running this version of gcc:
$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)

>From here: http://llvm.org/docs/GettingStarted.html#brokengcc
  "We routinely use GCC 3.3.3, 3.4.0, and Apple 4.0.1 successfully
with them (however, see important notes below)."
I'm not sure what the "important notes below" are for gcc 4.0.1 as
none of the notes I saw below seemed relevant to 4.0.1.

So my example (posted previously) is pretty simple.  As far as I can
tell, it is the canonical way to compile "int main(int argc) {return
argc;}".  If that doesn't work, how can gcc 4.0.1 be working at all?
Just trying to figure out what is going on here and how to proceed.

Daniel

>> Any clue as to why when we attempt to follow the very simple example
>> in the llvm-2.5 release docs/tutorial/JITTutorial1.html we construct a
>> module state that verifies but then when we ask it to emit, we get a
>> stack overflow from LLVM?
>
> The most likely reason is that you didn't follow the instructions, and
> are using a known-broken GCC:
> http://llvm.org/docs/GettingStarted.html#brokengcc
>
> or that you've found a new one.
>
> -Chris

From sanjiv.gupta at microchip.com  Mon Oct  5 13:11:42 2009
From: sanjiv.gupta at microchip.com (Sanjiv Gupta)
Date: Mon, 05 Oct 2009 23:41:42 +0530
Subject: [LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
In-Reply-To: <4AC2CAA6.1060601@microchip.com>
References: <4AC1F0C6.9030103@microchip.com>
	<4AC1F8F5.7020707@free.fr>	<4AC23940.5090804@microchip.com>
	<4AC2CAA6.1060601@microchip.com>
Message-ID: <4ACA36DE.6090609@microchip.com>

Sanjiv Gupta wrote:
> Sanjiv Gupta wrote:
>   
>> Duncan Sands wrote:
>>   
>>     
>>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing
>>> with float (32 bits).  So it's not just a matter of changing the libcall
>>> return type.
>>>
>>>     
>>>       
>> Yes, we are dealing with 32-bits only. But why the cmp libcalls have to 
>> return a 32-bit value.
>> e.g. Our libcall for comparing two floats is
>>
>>   char _eq_f32 (float a, float b);
>>
>> rather than
>>  
>>   long _eq_f32 (float a, float b);
>>
>>
>> - Sanjiv
>>   
>>     
> Why not use TLI.getSetCCResultType () ?
>
> - Sanjiv
>
>   
Duncan,
Any thoughts ?
Or am I missing something very obvious here?

- Sanjiv

From deeppatel1987 at gmail.com  Mon Oct  5 14:08:07 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Mon, 5 Oct 2009 19:08:07 +0000
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
Message-ID: <305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>

On Mon, Oct 5, 2009 at 2:21 PM, Rafael Espindola <espindola at google.com> wrote:
> 2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>:
>> There needs to be a build step
>> somewhere in llvm-gcc that copies it into libexec/<gcc
>> poop>/libLLVMgold.so, but I've been doing that manually for now.
>
> Yes, this is bad. The problem is that we build the plugin in llvm, not
> llvm-gcc. Another option is to add a new search directory to llvm-gcc.
> That way you could configure llvm-gcc with a --gold-plugin-dir=<path>
> and the resulting binary would search there. This would work nicely
> when using an already installed llvm copy.

That would work for gold, but what about nm, etc.?

>> It doesn't seem that simple use of -O4 results in the plugin learning
>> what subtarget is desired. I presume that the llvm-gcc driver needs to
>> pass -mcpu down through collect2 into ld somehow. Has anybody solved
>> this already? Perhaps we should finally just put the feature string
>> into the bitcode?
>
> Interesting. It is probably better to pass it via the command line. I
> will try to take a look at it. Do you have a small testcase?

I have no idea how to reduce this.

Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
--with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
known to the gold plugin. I'd think the same would be true for any
cross-compiler. Note that self-hosting X86 will eventually use a CPUID
instruction to determine the proper subtarget on the fly so it will
usually be correct.

deep

From espindola at google.com  Mon Oct  5 15:04:16 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 5 Oct 2009 16:04:16 -0400
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
Message-ID: <38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>

> That would work for gold, but what about nm, etc.?

You would still need to copy it :-(

> I have no idea how to reduce this.
>
> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
> bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
> known to the gold plugin. I'd think the same would be true for any
> cross-compiler. Note that self-hosting X86 will eventually use a CPUID
> instruction to determine the proper subtarget on the fly so it will
> usually be correct.

I will try to take a look, but it will take some time.

> deep
>


Cheers,
-- 
Rafael ?vila de Esp?ndola


From deeppatel1987 at gmail.com  Mon Oct  5 15:21:34 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Mon, 5 Oct 2009 20:21:34 +0000
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
	<38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>
Message-ID: <305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>

On Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote:
>> I have no idea how to reduce this.
>>
>> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
>> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
>> bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
>> known to the gold plugin. I'd think the same would be true for any
>> cross-compiler. Note that self-hosting X86 will eventually use a CPUID
>> instruction to determine the proper subtarget on the fly so it will
>> usually be correct.
>
> I will try to take a look, but it will take some time.

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

I'd expect that gold will need an option that tells it that some
following option or options are to be passed to the plugin. The plugin
API will need to pass these flags down. Any suggestions here that
would be compatible with the FSF view of the universe would be
welcome.

I assume the plugin's options should be either the existing cl::opt
ones (-mcpu, etc.) or similar to the llc ones.

deep

From Micah.Villmow at amd.com  Mon Oct  5 15:36:05 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Mon, 5 Oct 2009 13:36:05 -0700
Subject: [LLVMdev] Backend Function Pass
Message-ID: <493720826E33B1459E7F5C253E6D4BB584A113@ssanexmb2.amd.com>

Are there any known examples of a backend using a function pass, not a
machine function pass, to do LLVM-LLVM transformations right before
ISelDagToDag?

 

Thanks,

Micah

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091005/81ec49f9/attachment.html 

From espindola at google.com  Mon Oct  5 16:09:01 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 5 Oct 2009 17:09:01 -0400
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
	<38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>
	<305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
Message-ID: <38a0d8450910051409r68b00ff3ia697f26c7e2b0289@mail.gmail.com>

> If we can decide the way we want the options passed, I can take a stab
> at it (or more likely Viktor will).

The linker has a -plugin-opt option. You probably do something like

-fplugin-opt=-mcpu=

> I'd expect that gold will need an option that tells it that some
> following option or options are to be passed to the plugin. The plugin
> API will need to pass these flags down. Any suggestions here that
> would be compatible with the FSF view of the universe would be
> welcome.

On the gcc plugin we just reexec gcc, so the plugin options are gcc
options. Not sure if there is much to be gained here since the two
plugins are independent.

> I assume the plugin's options should be either the existing cl::opt
> ones (-mcpu, etc.) or similar to the llc ones.

You are free to name it, but using something similar to a llc option
is probably a good idea.

> deep
>


Cheers,
-- 
Rafael ?vila de Esp?ndola


From gohman at apple.com  Mon Oct  5 16:33:44 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 5 Oct 2009 14:33:44 -0700
Subject: [LLVMdev] Functions: sret and readnone
In-Reply-To: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com>
Message-ID: <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com>


On Oct 5, 2009, at 7:21 AM, Stephan Reiter wrote:

> Hi all,
>
> I'm currently building a DSL for a computer graphics project that is
> not unlike NVIDIA's Cg. I have an intrinsic with the following
> signature
>
> float4 sample(texture tex, float2 coords);
>
> that is translated to this LLVM IR code:
>
> declare void @"sample"(%float4* noalias nocapture sret, %texture,
> $float2) nounwind readnone
>
> The type float4 is basically an array of four floats, which cannot be
> returned directly on an x86 using the traditional calling conventions
> but only via the sret mechanism.

Is there a reason it needs to be an array? A vector of four floats
wouldn't have this problem, if that's an option.

Dan


From vkutuzov at accesssoftek.com  Mon Oct  5 16:31:17 2009
From: vkutuzov at accesssoftek.com (Viktor Kutuzov)
Date: Mon, 5 Oct 2009 14:31:17 -0700
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
	<38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>,
	<305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
Message-ID: <6AE1604EE3EC5F4296C096518C6B77EEED816D3E@mail.accesssoftek.com>

> I'd expect that gold will need an option that tells it that some
> following option or options are to be passed to the plugin. The plugin
> API will need to pass these flags down.

This is already in place. Linker command line options could look like

-plugin pathname [ -plugin-opt arg1 ] [ -plugin-opt arg2 ] ... 

gold will load plug-in by pathname and pass to it the arguments arg1, arg2, etc. in the same order in which they appear on the command line.

-Viktor

________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sandeep Patel [deeppatel1987 at gmail.com]
Sent: Monday, October 05, 2009 1:21 PM
To: Rafael Espindola
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] getting gold plugin to work?

On Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote:
>> I have no idea how to reduce this.
>>
>> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8
>> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the
>> bitcode will be "armv7-eabi" but the actual CPU subtarget won't be
>> known to the gold plugin. I'd think the same would be true for any
>> cross-compiler. Note that self-hosting X86 will eventually use a CPUID
>> instruction to determine the proper subtarget on the fly so it will
>> usually be correct.
>
> I will try to take a look, but it will take some time.

If we can decide the way we want the options passed, I can take a stab
at it (or more likely Viktor will).

I'd expect that gold will need an option that tells it that some
following option or options are to be passed to the plugin. The plugin
API will need to pass these flags down. Any suggestions here that
would be compatible with the FSF view of the universe would be
welcome.

I assume the plugin's options should be either the existing cl::opt
ones (-mcpu, etc.) or similar to the llc ones.

deep
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From anton at korobeynikov.info  Mon Oct  5 16:50:12 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 6 Oct 2009 01:50:12 +0400
Subject: [LLVMdev] Backend Function Pass
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB584A113@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB584A113@ssanexmb2.amd.com>
Message-ID: <b087fca00910051450s570ef68et98ac6e7c9499d9e2@mail.gmail.com>

Hello

> Are there any known examples of a backend using a function pass, not a
> machine function pass, to do LLVM-LLVM transformations right before
> ISelDagToDag?
Just schedule pass as normal, before doing codegen.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From dag at cray.com  Mon Oct  5 17:14:02 2009
From: dag at cray.com (David Greene)
Date: Mon, 5 Oct 2009 17:14:02 -0500
Subject: [LLVMdev] Linker Question
Message-ID: <200910051714.02569.dag@cray.com>

Say I have the following code:

main.c:

  void foo(char *, ...);
  void bar(int, ...);


  int main(void)
  {
    foo("foo", 1);
    bar(1, 2, 3, "bar");

    return 0;
  }

foobar.c:

  int printf(const char *, ...);

  void foo(const char *str, int i)
  {
    printf("%s: %d\n", str, i);
  }

  void bar(int i, int j, int k, const char *str)
  {
    printf("%s sum: %d\n", str, i+j+k);
  }

When I compile these separately and run llvm-ld -disable-opt I get this 
unfortunate sequence:

define i32 @main() nounwind {
entry:
  %retval = alloca i32                            ; <i32*> [#uses=2]
  %0 = alloca i32                                 ; <i32*> [#uses=2]
  %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
  call void (i8*, ...)* bitcast (void (i8*, i32)* @foo to void (i8*, ...)*)
(i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), i32 1) nounwind
  call void (i32, ...)* bitcast (void (i32, i32, i32, i8*)* @bar to void 
(i32, ...)*)(i32 1, i32 2, i32 3, i8* getelementptr inbounds ([4 x i8]* 
@.str1, i64 0, i64 0)) nounwind

It's unfortunate because the bitcast gets in the way.  For example, looking
at the ValueMap in the linker one would expect a Function to map to a 
Function.  That's not true here.  A Function maps to a bitcast.  It also
means the generated code will be suboptimal on targets like x86-64 that 
require extra processing for vararg calls.

This happens because RecursiveResolveTypes in LinkModules.cpp doesn't 
understand that a "more fully specified" function argument list is compatible 
with a "less fully specified" one and that it should be perfectly fine to 
resolve the type to the more specified one.

Would it break things horribly if I went in and taught RecursiveResolveTypes
how to handle this or would that violate some deep-level assumption?

                                 -Dave

From luoyonggang at gmail.com  Mon Oct  5 17:17:59 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Tue, 6 Oct 2009 06:17:59 +0800
Subject: [LLVMdev] Hi, everyone, fail on building c-index-test
In-Reply-To: <F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
Message-ID: <806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com>

Is there anyone get the time to apply this patch?

2009/10/2, Douglas Gregor <dgregor at apple.com>:
>
> On Oct 1, 2009, at 6:36 AM, ???(Yonggang Luo) wrote:
>
>> At the first glance,  it's coming with that c-index-test is just
>> only containing c files (without cpp(cxx,c++) files).
>>
>> So cmake recognize it as pure C project,
>> and so it's link options that resident in link.txt is
>> /usr/bin/gcc     CMakeFiles/c-index-test.dir/c-index-test.c.o  -
>> o ../../../../bin/c-index-test -rdynamic ../../../../lib/
>> libCIndex.so ../../../../lib/libclangIndex.a ../../../../lib/
>> libclangFrontend.a ../../../../lib/libclangSema.a ../../../../lib/
>> libclangAST.a ../../../../lib/libclangLex.a ../../../../lib/
>> libclangBasic.a ../../../../lib/libLLVMBitReader.a ../../../../lib/
>> libLLVMMC.a ../../../../lib/libLLVMCore.a ../../../../lib/
>> libLLVMSupport.a ../../../../lib/libLLVMSystem.a -ldl -lpthread -Wl,-
>> rpath,/home/dreamkxd/llvm/lib
>>
>> And so, it's won't linkage with C++ library. So it's failure to
>> compiling the c-index-test project
>>
>> Is there any solution to this problem?
>
> You're building using CMake? Try modifying tools/CIndex/CMakeLists.txt
> by adding the following command at the end:
>
>    set_target_properties(CIndex
>      PROPERTIES
>      LINKER_LANGUAGE CXX)
>
> If that works for you, please tell me so I can commit the change to svn.
>
> 	- Doug

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From clattner at apple.com  Mon Oct  5 17:21:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 15:21:17 -0700
Subject: [LLVMdev] Linker Question
In-Reply-To: <200910051714.02569.dag@cray.com>
References: <200910051714.02569.dag@cray.com>
Message-ID: <9749D8FC-5450-4AD8-B592-30D2BBAC8388@apple.com>

On Oct 5, 2009, at 3:14 PM, David Greene wrote:
> When I compile these separately and run llvm-ld -disable-opt I get  
> this
> unfortunate sequence:
>
> define i32 @main() nounwind {
> entry:
>  %retval = alloca i32                            ; <i32*> [#uses=2]
>  %0 = alloca i32                                 ; <i32*> [#uses=2]
>  %"alloca point" = bitcast i32 0 to i32          ; <i32> [#uses=0]
>  call void (i8*, ...)* bitcast (void (i8*, i32)* @foo to void  
> (i8*, ...)*)
> (i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), i32 1)  
> nounwind
>  call void (i32, ...)* bitcast (void (i32, i32, i32, i8*)* @bar to  
> void
> (i32, ...)*)(i32 1, i32 2, i32 3, i8* getelementptr inbounds ([4 x  
> i8]*
> @.str1, i64 0, i64 0)) nounwind
>
> It's unfortunate because the bitcast gets in the way.  For example,  
> looking
> at the ValueMap in the linker one would expect a Function to map to a
> Function.  That's not true here.  A Function maps to a bitcast.  It  
> also
> means the generated code will be suboptimal on targets like x86-64  
> that
> require extra processing for vararg calls.

Yep, it's pretty ugly.

> This happens because RecursiveResolveTypes in LinkModules.cpp doesn't
> understand that a "more fully specified" function argument list is  
> compatible
> with a "less fully specified" one and that it should be perfectly  
> fine to
> resolve the type to the more specified one.
>
> Would it break things horribly if I went in and taught  
> RecursiveResolveTypes
> how to handle this or would that violate some deep-level assumption?

This is intentional, but instcombine should clean it up.  Are you not  
seeing this?  If not, instcombine should be improved.

-Chris

From dgregor at apple.com  Mon Oct  5 17:30:21 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Mon, 5 Oct 2009 15:30:21 -0700
Subject: [LLVMdev] Hi, everyone, fail on building c-index-test
In-Reply-To: <806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
	<806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com>
Message-ID: <50EF0731-3436-4F53-B8D5-2347F97EA359@apple.com>

On Oct 5, 2009, at 3:17 PM, ???(Yonggang Luo) wrote:

> Is there anyone get the time to apply this patch?

I've committed my suggested fix. There's no point in setting the  
LINKER_LANGUAGE property of every LLVM library, because CMake figures  
out the right language based on the file extensions of the source files.

	- Doug

> 2009/10/2, Douglas Gregor <dgregor at apple.com>:
>>
>> On Oct 1, 2009, at 6:36 AM, ???(Yonggang Luo) wrote:
>>
>>> At the first glance,  it's coming with that c-index-test is just
>>> only containing c files (without cpp(cxx,c++) files).
>>>
>>> So cmake recognize it as pure C project,
>>> and so it's link options that resident in link.txt is
>>> /usr/bin/gcc     CMakeFiles/c-index-test.dir/c-index-test.c.o  -
>>> o ../../../../bin/c-index-test -rdynamic ../../../../lib/
>>> libCIndex.so ../../../../lib/libclangIndex.a ../../../../lib/
>>> libclangFrontend.a ../../../../lib/libclangSema.a ../../../../lib/
>>> libclangAST.a ../../../../lib/libclangLex.a ../../../../lib/
>>> libclangBasic.a ../../../../lib/libLLVMBitReader.a ../../../../lib/
>>> libLLVMMC.a ../../../../lib/libLLVMCore.a ../../../../lib/
>>> libLLVMSupport.a ../../../../lib/libLLVMSystem.a -ldl -lpthread - 
>>> Wl,-
>>> rpath,/home/dreamkxd/llvm/lib
>>>
>>> And so, it's won't linkage with C++ library. So it's failure to
>>> compiling the c-index-test project
>>>
>>> Is there any solution to this problem?
>>
>> You're building using CMake? Try modifying tools/CIndex/ 
>> CMakeLists.txt
>> by adding the following command at the end:
>>
>>   set_target_properties(CIndex
>>     PROPERTIES
>>     LINKER_LANGUAGE CXX)
>>
>> If that works for you, please tell me so I can commit the change to  
>> svn.
>>
>> 	- Doug
>
> -- 
> ?????????
>
>         ??
> ?
> ???
> Yours
>    sincerely,
> Yonggang Luo



From dag at cray.com  Mon Oct  5 17:31:26 2009
From: dag at cray.com (David Greene)
Date: Mon, 5 Oct 2009 17:31:26 -0500
Subject: [LLVMdev] Linker Question
In-Reply-To: <9749D8FC-5450-4AD8-B592-30D2BBAC8388@apple.com>
References: <200910051714.02569.dag@cray.com>
	<9749D8FC-5450-4AD8-B592-30D2BBAC8388@apple.com>
Message-ID: <200910051731.27034.dag@cray.com>

On Monday 05 October 2009 17:21, Chris Lattner wrote:

> > Would it break things horribly if I went in and taught
> > RecursiveResolveTypes
> > how to handle this or would that violate some deep-level assumption?
>
> This is intentional, but instcombine should clean it up.  Are you not
> seeing this?  If not, instcombine should be improved.

The problem is I need to examine this before instcombine and do various 
nefarious things like spitting out IR and/or generating code without any 
modifications to improve debuggability of our compiler.  Why is this 
intentional?

I've coded up the necessary linker changes but the build is waiting on NFS and
a tape drive.  Grr...

                              -Dave

From gohman at apple.com  Mon Oct  5 17:46:43 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 5 Oct 2009 15:46:43 -0700
Subject: [LLVMdev] code generation goes into an infinite loop
In-Reply-To: <48f102b60910031506g581c0491i9b483dd7547fd715@mail.gmail.com>
References: <48f102b60910031506g581c0491i9b483dd7547fd715@mail.gmail.com>
Message-ID: <2AEE8444-89BB-4C20-9AD9-A821C849F53C@apple.com>


On Oct 3, 2009, at 3:06 PM, Daniel Wilkerson wrote:

> We seem to be creating an infinite loop in llvm while trying to
> implement the simplest possible code generation.  Specifically, we are
> trying to emit code for the following program, as it is easily
> testable from the command-line:
>
>    int main(int argc) { return argc; }
>
> We got our code generator to build and link with llvm.  When we run
> it, it pauses when running the PrintModulePass and then exits with a
> bus error.  I suspect that this is an infinite loop leading to a stack
> overflow.

Are you able to run this under a debugger to locate the
infinite loop?

Dan


From eli.friedman at gmail.com  Mon Oct  5 18:54:26 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 5 Oct 2009 16:54:26 -0700
Subject: [LLVMdev] SoftenSetCCOpernads in LegalizeFloatTypes.cpp
In-Reply-To: <4ACA36DE.6090609@microchip.com>
References: <4AC1F0C6.9030103@microchip.com> <4AC1F8F5.7020707@free.fr>
	<4AC23940.5090804@microchip.com> <4AC2CAA6.1060601@microchip.com>
	<4ACA36DE.6090609@microchip.com>
Message-ID: <f5aa3e9b0910051654s2d3cd658i5b70df3c906edb11@mail.gmail.com>

On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta
<sanjiv.gupta at microchip.com> wrote:
> Sanjiv Gupta wrote:
>> Sanjiv Gupta wrote:
>>
>>> Duncan Sands wrote:
>>>
>>>
>>>> Hi Sanjiv, I think a lot of the softening code assumes you are dealing
>>>> with float (32 bits). ?So it's not just a matter of changing the libcall
>>>> return type.
>>>>
>>>>
>>>>
>>> Yes, we are dealing with 32-bits only. But why the cmp libcalls have to
>>> return a 32-bit value.
>>> e.g. Our libcall for comparing two floats is
>>>
>>> ? char _eq_f32 (float a, float b);
>>>
>>> rather than
>>>
>>> ? long _eq_f32 (float a, float b);
>>>
>>>
>>> - Sanjiv
>>>
>>>
>> Why not use TLI.getSetCCResultType () ?
>>
>> - Sanjiv
>>
>>
> Duncan,
> Any thoughts ?
> Or am I missing something very obvious here?

getSetCCResultType has nothing to do with the result of a libcall; for
example, on x86 it's i8 even though any libcalls like that will return
an i32.  You really need a separate method.

-Eli


From eli.friedman at gmail.com  Mon Oct  5 19:02:09 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 5 Oct 2009 17:02:09 -0700
Subject: [LLVMdev] Linker Question
In-Reply-To: <200910051731.27034.dag@cray.com>
References: <200910051714.02569.dag@cray.com>
	<9749D8FC-5450-4AD8-B592-30D2BBAC8388@apple.com>
	<200910051731.27034.dag@cray.com>
Message-ID: <f5aa3e9b0910051702g1908c449s5d6234563bc42d34@mail.gmail.com>

On Mon, Oct 5, 2009 at 3:31 PM, David Greene <dag at cray.com> wrote:
> On Monday 05 October 2009 17:21, Chris Lattner wrote:
>
>> > Would it break things horribly if I went in and taught
>> > RecursiveResolveTypes
>> > how to handle this or would that violate some deep-level assumption?
>>
>> This is intentional, but instcombine should clean it up. ?Are you not
>> seeing this? ?If not, instcombine should be improved.
>
> The problem is I need to examine this before instcombine and do various
> nefarious things like spitting out IR and/or generating code without any
> modifications to improve debuggability of our compiler. ?Why is this
> intentional?

The type system fundamentally depends on identity; you can't just
screw around with types like that.  If I had to guess, things will
explode if something uses a pointer to such a function in some way
other than calling it.

If you really need this, you can always copy the relevant code out of
instcombine and create your own pass to which just performs this fix.

-Eli


From kennethuil at gmail.com  Mon Oct  5 20:09:05 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 5 Oct 2009 20:09:05 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
Message-ID: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>

I've gotten my front-end to compile with the 2.6 branch and with trunk
(not with both; I have to fiddle with a few things when switching),
and it refuses to give me an execution engine.

My link flags include everything coming from "llvm-config --libs".
Nevertheless, the error string coming back from
ExecutionEngine::create is:

JIT has not been linked in

Is this a known problem?  Is there something I should be doing that I
wasn't doing in 2.5?

From deeppatel1987 at gmail.com  Mon Oct  5 20:18:42 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Tue, 6 Oct 2009 01:18:42 +0000
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <38a0d8450910051409r68b00ff3ia697f26c7e2b0289@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>
	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>
	<38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>
	<305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
	<38a0d8450910051409r68b00ff3ia697f26c7e2b0289@mail.gmail.com>
Message-ID: <305d6f60910051818g55a50acei7697b0cd6b0579cc@mail.gmail.com>

On Mon, Oct 5, 2009 at 9:09 PM, Rafael Espindola <espindola at google.com> wrote:
>> If we can decide the way we want the options passed, I can take a stab
>> at it (or more likely Viktor will).
>
> The linker has a -plugin-opt option. You probably do something like
>
> -fplugin-opt=-mcpu=
>
...
>> I assume the plugin's options should be either the existing cl::opt
>> ones (-mcpu, etc.) or similar to the llc ones.
>
> You are free to name it, but using something similar to a llc option
> is probably a good idea.

LINK_COMMAND_SPEC in gcc.c will need to change to add:
    %{O*:-plugin-opt=-O%*} \
    %{w:-plugin-opt=-w} \
    %{f*:-plugin-opt=-f%*} \
    ${m*:-plugin-opt=-m%*} \

and then the plugin will need to have an argument translation process
similar to llvm-gcc's LLVM_SET_TARGET_OPTIONS,
LLVM_SET_MACHINE_OPTIONS, and LLVM_SET_SUBTARGET_FEATURES as well as
all the logic in llvm-backend.cpp for translating options. I don't see
any way to unify this logic with the llvm-gcc logic because llvm-gcc's
decisions are derived from global state instead of a direct argument
translation process. Yuck.

Opinions welcome.

deep

From Axel.Naumann at cern.ch  Mon Oct  5 20:27:56 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Tue, 6 Oct 2009 03:27:56 +0200
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
Message-ID: <4ACA9D1C.7090601@cern.ch>

Hi,

#include "JIT.h" will do.

Cheers, Axel.

On 2009-10-06 03:09, Kenneth Uildriks wrote:
> I've gotten my front-end to compile with the 2.6 branch and with trunk
> (not with both; I have to fiddle with a few things when switching),
> and it refuses to give me an execution engine.
> 
> My link flags include everything coming from "llvm-config --libs".
> Nevertheless, the error string coming back from
> ExecutionEngine::create is:
> 
> JIT has not been linked in
> 
> Is this a known problem?  Is there something I should be doing that I
> wasn't doing in 2.5?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 


From kennethuil at gmail.com  Mon Oct  5 20:52:22 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 5 Oct 2009 20:52:22 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <4ACA9D1C.7090601@cern.ch>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<4ACA9D1C.7090601@cern.ch>
Message-ID: <400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>

On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote:
> Hi,
>
> #include "JIT.h" will do.

Thanks.  That was exactly what I needed to progress to the next error
("Unable to find target for this triple (no targets are registered)")

As soon as I get this front-end working with the trunk, I'll start
submitting patches that add calls to the C-API; my front-end generates
code-generation-code that relies on it rather heavily, and there are
gaps I'd like to fill in.

From rnk at mit.edu  Mon Oct  5 21:00:49 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Mon, 5 Oct 2009 22:00:49 -0400
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com> 
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
Message-ID: <9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>

On Mon, Oct 5, 2009 at 9:52 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote:
>> Hi,
>>
>> #include "JIT.h" will do.
>
> Thanks. ?That was exactly what I needed to progress to the next error
> ("Unable to find target for this triple (no targets are registered)")

You probably need to call InitializeNativeTarget() or something.  IMO,
LLVM should probably do this by default as part of constructing a JIT.

Reid

> As soon as I get this front-end working with the trunk, I'll start
> submitting patches that add calls to the C-API; my front-end generates
> code-generation-code that relies on it rather heavily, and there are
> gaps I'd like to fill in.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From nicholas at mxc.ca  Tue Oct  6 01:05:55 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 05 Oct 2009 23:05:55 -0700
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <38a0d8450910051409r68b00ff3ia697f26c7e2b0289@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>	<38a0d8450910050721v7816d128ke04c7c7574929e55@mail.gmail.com>	<305d6f60910051208n486b804di6adbe896c72aede7@mail.gmail.com>	<38a0d8450910051304q64288804u6a8e71395aca18f6@mail.gmail.com>	<305d6f60910051321h46c46eacsc1f610ed9d2cacc1@mail.gmail.com>
	<38a0d8450910051409r68b00ff3ia697f26c7e2b0289@mail.gmail.com>
Message-ID: <4ACADE43.1000905@mxc.ca>

Rafael Espindola wrote:
>> If we can decide the way we want the options passed, I can take a stab
>> at it (or more likely Viktor will).
> 
> The linker has a -plugin-opt option. You probably do something like
> 
> -fplugin-opt=-mcpu=

The gold plugin has its own option list, it doesn't pass options through 
to LLVM -- which come to think of it would probably be a really good 
idea. Adding a call to "cl::ParseCommandLineOptions" for the unknown 
options would be a good change to have.

Nick

>> I'd expect that gold will need an option that tells it that some
>> following option or options are to be passed to the plugin. The plugin
>> API will need to pass these flags down. Any suggestions here that
>> would be compatible with the FSF view of the universe would be
>> welcome.
> 
> On the gcc plugin we just reexec gcc, so the plugin options are gcc
> options. Not sure if there is much to be gained here since the two
> plugins are independent.
> 
>> I assume the plugin's options should be either the existing cl::opt
>> ones (-mcpu, etc.) or similar to the llc ones.
> 
> You are free to name it, but using something similar to a llc option
> is probably a good idea.
> 
>> deep
>>
> 
> 
> Cheers,


From viridia at gmail.com  Tue Oct  6 01:08:56 2009
From: viridia at gmail.com (Talin)
Date: Mon, 5 Oct 2009 23:08:56 -0700
Subject: [LLVMdev] More questions about appending linkage
Message-ID: <d1b71f830910052308k7c37d862h2051f944fcfda494@mail.gmail.com>

So, I was in the process of writing a custom LLVM pass (my first one, yay!)
to handle the problem of measuring the length of an appending linkage array.
The approach I was taking was pretty simple: Iterate through all of the
module's global variables until I find one that is trying to calculate the
end of an appending-linkage array, which looks like this:

  @_moduleListEnd = constant [1 x %Module*]* getelementptr ([1 x %Module*]*
bitcast ([62 x %Module*]* @_moduleList to [1 x %Module*]*), i32 1) ; <[1 x
%Module*]**> [#uses=0]

Once I detected this particular pattern, I'd simply remove the bitcast
instruction so that the GEP is operating on the real type of the array.

Unfortunately, this runs in to a couple problems. The first is that I don't
really understand how appending linkage interacts with dead global
elimination. What I want is for the appending linkage array to only contain
the variables that survived dead global elimination; And I don't want the
global references in the array itself to cause the referred global to be
considered "live".

It's easy to envision if you think in terms of C++ static constructors: Say
you are linking with a static library that has a large number of modules,
some of which contains static constructor functions. You have some
appending-linkage array which is used to collect together pointers to all of
the functions that need to be executed before main(). However, you don't
want to include functions for classes that aren't transitively reachable
from your main function, otherwise you end up pulling in the entire library
and your program gets bloated.

The other problem is that you want to fix up the appending linkage arrays
after dead global elimination. Unfortunately, at that point the internalize
pass has changed the linkage types of all your appending arrays to
"internal". So there's no way for my trick to work, since it can't tell
which arrays to fix up.

In the case of static C++ constructors, my understanding is that the linker
has special knowledge of that particular array. But I don't want to
hard-code the name of a particular global into my linker if I can help it.
What I need is some way to mark or annotate those variables to tell the
linker to perform the fixup.

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091005/caad7b3d/attachment.html 

From clattner at apple.com  Tue Oct  6 01:43:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 5 Oct 2009 23:43:01 -0700
Subject: [LLVMdev] Linker Question
In-Reply-To: <200910051731.27034.dag@cray.com>
References: <200910051714.02569.dag@cray.com>
	<9749D8FC-5450-4AD8-B592-30D2BBAC8388@apple.com>
	<200910051731.27034.dag@cray.com>
Message-ID: <1AAF927F-A953-4A01-B505-FA3C2BC52428@apple.com>


On Oct 5, 2009, at 3:31 PM, David Greene wrote:

> On Monday 05 October 2009 17:21, Chris Lattner wrote:
>
>>> Would it break things horribly if I went in and taught
>>> RecursiveResolveTypes
>>> how to handle this or would that violate some deep-level assumption?
>>
>> This is intentional, but instcombine should clean it up.  Are you not
>> seeing this?  If not, instcombine should be improved.
>
> The problem is I need to examine this before instcombine and do  
> various
> nefarious things like spitting out IR and/or generating code without  
> any
> modifications to improve debuggability of our compiler.  Why is this
> intentional?

It is intentional because there are two things going on here: the  
linker needs to unify the prototypes, then something needs to massage  
the call to pass the arguments to the new prototype.  Just violating  
the type system won't work.  Doing this in two steps (the linker does  
something simple and always correct + instcombine improving  
performance/analyzability) is much better than the old and buggy thing  
we had before where the linker tried to do both.

-Chris


From pietreka at gmail.com  Tue Oct  6 07:10:50 2009
From: pietreka at gmail.com (Artur Pietrek)
Date: Tue, 6 Oct 2009 14:10:50 +0200
Subject: [LLVMdev] TableGen question - how to split a 64bit operation to two
	32bit
Message-ID: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>

Hi all,I'm working on my own backend for a custom CPU. I have defined paired
registers for 64bit operations, however to set a 64bit paired register with
64bit immediate I have to set each register in that pair separately with the
higher and the lower 32bits of the immediate.
Could anyone give me an advice how to describe it in *InstructionInfo.td or
point me to something similar in the LLVM source code? (I was looking for it
but couldn't find it)

Thanks,
Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091006/eec456ae/attachment.html 

From anton at korobeynikov.info  Tue Oct  6 08:09:13 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Tue, 6 Oct 2009 17:09:13 +0400
Subject: [LLVMdev] TableGen question - how to split a 64bit operation to
	two 32bit
In-Reply-To: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>
References: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>
Message-ID: <b087fca00910060609l6f8f0c2fq73b8c9c3afd61aa9@mail.gmail.com>

Hello, Artur

> I'm working on my own backend for a custom CPU. I have defined paired
> registers for 64bit operations, however to set a 64bit paired register with
> 64bit immediate I have to set each register in that pair separately with the
> higher and the lower 32bits of the immediate.
> Could anyone give me an advice how to describe it in *InstructionInfo.td or
> point me to something similar in the LLVM source code? (I was looking for it
> but couldn't find it)
There are several possible ways of doing so. One is to work at
asmprinter level. Also, many processors have separate instructions to
set e.g. low and high 16 bits of the whole 32 bit register. You might
want to see, how the stuff is done there (you'll need a custom operand
matching function + transform). See, e.g. arm, systemz, powerpc
backends.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From stephan.reiter at gmail.com  Tue Oct  6 02:00:21 2009
From: stephan.reiter at gmail.com (Stephan)
Date: Tue, 6 Oct 2009 00:00:21 -0700 (PDT)
Subject: [LLVMdev] Functions: sret and readnone
In-Reply-To: <7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com>
References: <135ebb010910050721t68118e75na082443e41c01d53@mail.gmail.com> 
	<7A62B2C6-4FF3-4BF6-80F7-57ABB25BE0BA@apple.com>
Message-ID: <5612891e-3fbf-4ff9-96da-56abc7d44086@o36g2000vbl.googlegroups.com>


On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote:
>
> Is there a reason it needs to be an array? A vector of four floats
> wouldn't have this problem, if that's an option.
>

Unfortunately that's not an option. At the moment I'm restricting
myself to the use of scalar code only, in order to be able to
vectorize the code easily later (e.g., float4 as it is now will then
become an array of four vectors for parallel processing of n (probably
4, SSE) pixels). But thanks for coming up with this idea!

Chris, I'll take a look at the AliasAnalysis functionality. Depending
on how much effort it is to implement a solution I might follow this
approach. If not, there's still Kenneth's new code generator to look
forward to. :)

Thanks,
Stephan

From grosbach at apple.com  Tue Oct  6 10:39:00 2009
From: grosbach at apple.com (Jim Grosbach)
Date: Tue, 6 Oct 2009 08:39:00 -0700
Subject: [LLVMdev] TableGen question - how to split a 64bit operation to
	two 32bit
In-Reply-To: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>
References: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>
Message-ID: <223225FA-95DE-47C0-B5F9-EA61827E16B9@apple.com>

Hi Artur,

The Thumb2 target (in lib/Targets/ARM/ARMInstrThumb2.td) materializes  
a 32-bit constant by a two-instruction sequence to load the low and  
high half-words. It's not pretty, but it works. The pattern is at the  
bottom of the file.

Regards,
-Jim

On Oct 6, 2009, at 5:10 AM, Artur Pietrek wrote:

> Hi all,
> I'm working on my own backend for a custom CPU. I have defined  
> paired registers for 64bit operations, however to set a 64bit paired  
> register with 64bit immediate I have to set each register in that  
> pair separately with the higher and the lower 32bits of the immediate.
> Could anyone give me an advice how to describe it in  
> *InstructionInfo.td or point me to something similar in the LLVM  
> source code? (I was looking for it but couldn't find it)
>
> Thanks,
> Artur
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From kennethuil at gmail.com  Tue Oct  6 14:13:12 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 14:13:12 -0500
Subject: [LLVMdev] Some additions to the C bindings
Message-ID: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>

My front-end is sync'd with the trunk now, and working well, but it
required some additional functions exposed in the C bindings.  I
hereby submit them for review and approval for inclusion in the trunk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbindings.patch
Type: application/octet-stream
Size: 7268 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091006/274b4675/attachment.obj 

From kennethuil at gmail.com  Tue Oct  6 14:39:54 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 14:39:54 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
Message-ID: <400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>

My front-end is humming along beautifully now with the LLVM trunk.  A
few upgrade notes for anyone who is interested:

1. Not surprisingly, everything in your front-end needs to be
recompiled; object layouts have changed.  My generated code was
calling some name-mangled stuff in the C++ libraries, and using
struct/class definitions defined therein, and it fell over hard when I
ran it against the trunk libraries.  I ripped all that stuff out and
added what I needed to the C bindings.

2. Linkage enums have changed.  Since my front-end doesn't understand
C, I had ported some LLVM definitions over so that I could use them in
my language.  That port, of course, was not automatically updated when
I built against the trunk, so I ended up with global linkage settings
that I wasn't expecting.  This led to:

3. llc gets very unhappy if you give an unnamed global variable weak
linkage.  This is not surprising, since weak linkage uses name
matching and doesn't make sense for things that have no name.
Updating my linkage enum port cleared that up for me.

4. The set of library names to link against has changed considerably.

5. C bindings to ExecutionEngine stuff have moved out of libCore.a.

From shuguang.feng at gmail.com  Tue Oct  6 15:33:04 2009
From: shuguang.feng at gmail.com (Shuguang Feng)
Date: Tue, 6 Oct 2009 13:33:04 -0700 (PDT)
Subject: [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] &
	Question: Preserving ProfileInfo for backend.)
In-Reply-To: <62cd7614-dae8-4e34-ace1-786c5dbc0c0f@h13g2000yqk.googlegroups.com>
References: <4AA61556.6090300@gmx.at>
	<A3C8BF9D-AB3C-4B8F-BE22-17763508B52F@apple.com> 
	<4071a327-c2d3-4757-85a7-a1c4c4c10275@y21g2000yqn.googlegroups.com> 
	<4AA7EA1A.2020007@gmx.at>
	<d9bf7e58-6457-4344-be5a-22474c12d0b3@g31g2000yqc.googlegroups.com>
	<4AA8BA59.1000100@gmx.at>
	<4cb478d1-4cd9-4133-9bee-4ff07d3d97d9@j19g2000yqk.googlegroups.com>
	<4AA919F1.6070306@gmx.at>
	<62cd7614-dae8-4e34-ace1-786c5dbc0c0f@h13g2000yqk.googlegroups.com>
Message-ID: <7e4c4ac6-14fb-4114-8eef-bbe2d235b347@33g2000vbe.googlegroups.com>

I finally got a chance to sit down and stare at this again today.
>From what I can tell the ProfileInfoLoaderPass (LoaderPass) is
executing properly.  However, when I call &getAnalysis<ProfileInfo>()
I'm actually receiving a handle to the NoProfileInfo pass despite the
ordering of the passes that I see:

Target Data Layout
Create Garbage Collector Module Metadata
Basic Alias Analysis (default AA impl)
DWARF Information Writer
No Profile Information                      <---------- *This is being
returned to me by getAnalysis<ProfileInfo>
Module Information
  ModulePass Manager
    Profiling information loader            <---------- *This is what
I want a handle to
    FunctionPass Manager
      Preliminary module verification
      Dominator Tree Construction
      Module Verifier
      Natural Loop Construction
      Canonicalize natural loops
      Scalar Evolution Analysis
      Loop Pass Manager
        Loop Strength Reduction
      Lower Garbage Collection Instructions
      Remove unreachable blocks from the CFG
      Optimize for code generation
      Insert stack protectors
      X86 DAG->DAG Instruction Selection
      X86 FP_REG_KILL inserter
      X86 Maximal Stack Alignment Calculator
      <MY PASS RUNS HERE>

I'm guessing that this happens because both LoaderPass and
NoProfileInfo are part of the same AnalysisGroup (ProfileInfo) and
NoProfileInfo pass was registered as the *default* implementation.  I
couldn't find how to disable NoProfileInfo from running so I modified
the source code to make LoaderPass the default.  This allowed me to
grab the right handle in my MachineFunction pass but also lead me to
wonder 3 things:

1) Is my explanation for what was happening correct?
2) If so, what is the proper way to select between different
implementations of an AnalysisGroup?
3) I couldn't find anything in the source tree that explicitly called
createNoProfileInfoPass() so why is NoProfileInfo always being
executed?  Does this have to do with it being an ImmutablePass?

Thanks!

From kennethuil at gmail.com  Tue Oct  6 15:53:10 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 15:53:10 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
Message-ID: <400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>

On Tue, Oct 6, 2009 at 2:39 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> My front-end is humming along beautifully now with the LLVM trunk. ?A
> few upgrade notes for anyone who is interested:
>
> 1. Not surprisingly, everything in your front-end needs to be
> recompiled; object layouts have changed. ?My generated code was
> calling some name-mangled stuff in the C++ libraries, and using
> struct/class definitions defined therein, and it fell over hard when I
> ran it against the trunk libraries. ?I ripped all that stuff out and
> added what I needed to the C bindings.
>
> 2. Linkage enums have changed. ?Since my front-end doesn't understand
> C, I had ported some LLVM definitions over so that I could use them in
> my language. ?That port, of course, was not automatically updated when
> I built against the trunk, so I ended up with global linkage settings
> that I wasn't expecting. ?This led to:
>
> 3. llc gets very unhappy if you give an unnamed global variable weak
> linkage. ?This is not surprising, since weak linkage uses name
> matching and doesn't make sense for things that have no name.
> Updating my linkage enum port cleared that up for me.
>
> 4. The set of library names to link against has changed considerably.
>
> 5. C bindings to ExecutionEngine stuff have moved out of libCore.a.
>
6. When ExecutionEngine::create was called with parameter
"GVsWithCode" set to its default value of true, I got a segfault when
trying to get a pointer to one of my globals.  JIT::getMemoryForGV was
returning NULL in that case.  Explicitly passing false for
"GVsWithCode" cleared it up.


From rnk at mit.edu  Tue Oct  6 16:15:54 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Tue, 6 Oct 2009 17:15:54 -0400
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com> 
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com> 
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com> 
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com> 
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com> 
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
Message-ID: <9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>

> 6. When ExecutionEngine::create was called with parameter
> "GVsWithCode" set to its default value of true, I got a segfault when
> trying to get a pointer to one of my globals. ?JIT::getMemoryForGV was
> returning NULL in that case. ?Explicitly passing false for
> "GVsWithCode" cleared it up.

That's no good.  Could you send me a stack trace and explain how you
got that to happen?  I was the last one to touch that code.

In your case, I would definitely set that parameter to false.  For
some reason, OpenCL requires that code and globals be allocated
together contiguously, and because backwards compatibility with them
is somehow more important than doing the right thing, that's still the
default behavior.  See http://llvm.org/bugs/show_bug.cgi?id=4483 .

Reid


From kennethuil at gmail.com  Tue Oct  6 17:08:51 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 17:08:51 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
	<9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
Message-ID: <400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>

On Tue, Oct 6, 2009 at 4:15 PM, Reid Kleckner <rnk at mit.edu> wrote:
>> 6. When ExecutionEngine::create was called with parameter
>> "GVsWithCode" set to its default value of true, I got a segfault when
>> trying to get a pointer to one of my globals. ?JIT::getMemoryForGV was
>> returning NULL in that case. ?Explicitly passing false for
>> "GVsWithCode" cleared it up.
>
> That's no good. ?Could you send me a stack trace and explain how you
> got that to happen? ?I was the last one to touch that code.

Stack trace attached.  It's not very informative; it just tells us
that it's got a null pointer that it thinks is a pointer to the
global, and it's trying to initialize that global.

What I did was load a module from a MemoryBuffer, use an
ExistingModuleProvider to feed it to the ExecutionEngine, then start
looping through its globals and get their addresses so I can refer to
their values while compiling another module.  The segfault happened on
the first one it encountered, a linkonce constant int32.

I can try and reduce it for you if you need.  The comment above create
said that passing true was "unsafe", so I figured it was a known issue
and plowed ahead with the upgrade.
-------------- next part --------------

#0  0xb7d4cc1c in memcpy () from /lib/i686/cmov/libc.so.6
#1  0x08851ead in StoreIntToMemory (IntVal=@0xbfe685b0, Dst=0x0, StoreBytes=4)
    at ExecutionEngine.cpp:783
#2  0x08851f7d in llvm::ExecutionEngine::StoreValueToMemory (this=0x97596f8,
    Val=@0xbfe685a8, Ptr=0x0, Ty=0x970e5f4) at ExecutionEngine.cpp:809
#3  0x88542a8 in llvm::ExecutionEngine::InitializeMemory (this=0x97596f8,
    Init=0x9732d70, Addr=0x0) at ExecutionEngine.cpp:931
#4  0x0885471c in llvm::ExecutionEngine::EmitGlobalVariable (this=0x97596f8,
    GV=0x981d7a4) at ExecutionEngine.cpp:1062
#5  0x08855169 in llvm::ExecutionEngine::getPointerToGlobal (this=0x97596f8,
    GV=0x981d7a4) at ExecutionEngine.cpp:481

From kennethuil at gmail.com  Tue Oct  6 17:31:50 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 17:31:50 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<4ACA9D1C.7090601@cern.ch>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
	<9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
	<400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>
Message-ID: <400d33ea0910061531x2916ca8dqdc5df19447f3238f@mail.gmail.com>

On Tue, Oct 6, 2009 at 5:08 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Tue, Oct 6, 2009 at 4:15 PM, Reid Kleckner <rnk at mit.edu> wrote:
>>> 6. When ExecutionEngine::create was called with parameter
>>> "GVsWithCode" set to its default value of true, I got a segfault when
>>> trying to get a pointer to one of my globals. ?JIT::getMemoryForGV was
>>> returning NULL in that case. ?Explicitly passing false for
>>> "GVsWithCode" cleared it up.
>>
>> That's no good. ?Could you send me a stack trace and explain how you
>> got that to happen? ?I was the last one to touch that code.
>
> Stack trace attached. ?It's not very informative; it just tells us
> that it's got a null pointer that it thinks is a pointer to the
> global, and it's trying to initialize that global.
>
> What I did was load a module from a MemoryBuffer, use an
> ExistingModuleProvider to feed it to the ExecutionEngine, then start
> looping through its globals and get their addresses so I can refer to
> their values while compiling another module. ?The segfault happened on
> the first one it encountered, a linkonce constant int32.
>
> I can try and reduce it for you if you need. ?The comment above create
> said that passing true was "unsafe", so I figured it was a known issue
> and plowed ahead with the upgrade.
>
Also, the null pointer is coming from a call to JCE->allocateSpace().
This is a virtual function; I'm trying to discover what subclass it
is.


From Micah.Villmow at amd.com  Tue Oct  6 18:28:13 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 6 Oct 2009 16:28:13 -0700
Subject: [LLVMdev] What opt pass attempts implements this optimization?
Message-ID: <493720826E33B1459E7F5C253E6D4BB584A3DB@ssanexmb2.amd.com>

I have a very simple kernel that is generating very very bad code.

 

The basic kernel pseudo-code is as follows:

forloop(1 to n) {

  forloop(0 to j) {

  A

}

B

}

C

 

It is generating very ugly and inefficient code for a vector system
similar to the following pseudo-code:

if (n > 1) {

  if (j) {

                forloop(1 to n) {

                                forloop(0 to j) {

                                A

                                }

                                B

                }

               C

   } else {

                forloop(1 to n) {

                                B

                }

                C

   } 

} else {

C

}

 

I can understand how this would be good in a scalar system like x86, but
this is just bad on a vector system.

 

The reason this is bad because if a single branch is taken by a
work-item in a hardware thread(there are 64 work-items per hw thread),
then every single work-item in a hardware thread must execute that
branch. In this specific example, instead of every thread executing A, B
and C once, in the worst case(which is also happens 100% of the time),
every thread will execute C three times, B twice and A once. This also
does not take into account the cost of managing flow control on the
hardware, which is relatively expensive. This gets worse with the more
flow control I add in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091006/4b790bcf/attachment.html 

From kennethuil at gmail.com  Tue Oct  6 18:32:02 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 18:32:02 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <9a9942200910061549y1ec423fdt74b6aebce3ac3c63@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<400d33ea0910051852n302bb801jd1d1b84c70fba464@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
	<9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
	<400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>
	<400d33ea0910061531x2916ca8dqdc5df19447f3238f@mail.gmail.com>
	<9a9942200910061549y1ec423fdt74b6aebce3ac3c63@mail.gmail.com>
Message-ID: <400d33ea0910061632v71b0e4eer4725dd7b9a43df09@mail.gmail.com>

On Tue, Oct 6, 2009 at 5:49 PM, Reid Kleckner <rnk at mit.edu> wrote:
>> Also, the null pointer is coming from a call to JCE->allocateSpace().
>> This is a virtual function; I'm trying to discover what subclass it
>> is.
>
> So, there's JITEmitter::allocateSpace which overrides
> JITCodeEmitter::allocateSpace(), but *most* of the time it just calls
> JITCodeEmitter::allocateSpace(). ?In particular, it does that if the
> emitter is already emitting a function (BufferBegin will be non-null).
> ?If there is no current function, it asks the JITMemoryManager for
> some space (JITMemoryManager::allocateSpace), which looked broken the
> last time I checked, but should work in theory. ?I can't see any way
> that it would return NULL, though.
>
> Reid
>

It just occurred to me... in the case where it's failing, the
ExecutionEngine was trying to JIT a global, and it had never JITted
any functions!  I'll work up a small test case, but I think it's
relevant since the thing is trying to allocate the globals with the
functions.


From kennethuil at gmail.com  Tue Oct  6 18:45:27 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 18:45:27 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910061632v71b0e4eer4725dd7b9a43df09@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<9a9942200910051900h465f8a06gf9c3997f6000d6a1@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
	<9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
	<400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>
	<400d33ea0910061531x2916ca8dqdc5df19447f3238f@mail.gmail.com>
	<9a9942200910061549y1ec423fdt74b6aebce3ac3c63@mail.gmail.com>
	<400d33ea0910061632v71b0e4eer4725dd7b9a43df09@mail.gmail.com>
Message-ID: <400d33ea0910061645w2e0d620cp7246a354b380e65e@mail.gmail.com>

>
> It just occurred to me... in the case where it's failing, the
> ExecutionEngine was trying to JIT a global, and it had never JITted
> any functions! ?I'll work up a small test case, but I think it's
> relevant since the thing is trying to allocate the globals with the
> functions.
>

That was it!  The following small test program crashes in getPointerToGlobal:

#include "llvm/Module.h"
#include "llvm/Function.h"
#include "llvm/InlineAsm.h"
#include "llvm/Support/IRBuilder.h"
#include "llvm/ModuleProvider.h"
#include "llvm/ExecutionEngine/ExecutionEngine.h"
#include "llvm/Support/raw_os_ostream.h"
#include "llvm/Bitcode/ReaderWriter.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/Target/TargetSelect.h"
#include "llvm/ExecutionEngine/JIT.h"

#include <assert.h>

using namespace llvm;

static raw_stdout_ostream raw_cout;

int main(int argc, char** argv)
{
	// Test JITting a variable without JITting any functions.'
	Module* mod = new Module("test", getGlobalContext());
	GlobalVariable* gv = cast<GlobalVariable>(mod->getOrInsertGlobal("TestGV",
			Type::getInt32Ty(getGlobalContext())));
	gv->setInitializer(ConstantInt::get(
		Type::getInt32Ty(getGlobalContext()), 24601));

	ModuleProvider* modp = new ExistingModuleProvider(mod);
	InitializeNativeTarget();
	std::string errstring;

	ExecutionEngine* eeng = ExecutionEngine::create(modp, false, &errstring,
			CodeGenOpt::Default, true);
	if ( eeng == NULL )
	{
		raw_cout << errstring << "\n";
		exit(-1);
	}
	raw_cout << "Fixing to get pointer to global\n";
	void* gvp = eeng->getPointerToGlobal(gv);
	raw_cout << "Got pointer to global\n";
	raw_cout << "gv = " << *((int*)gvp) << "\n";
	exit(0);
}


From kennethuil at gmail.com  Tue Oct  6 18:47:59 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 18:47:59 -0500
Subject: [LLVMdev] 2.6/trunk Execution Engine question
In-Reply-To: <400d33ea0910061645w2e0d620cp7246a354b380e65e@mail.gmail.com>
References: <400d33ea0910051809j22027150q67da761e9342eb8b@mail.gmail.com>
	<400d33ea0910051909g7382b4d4jf43e625a83b76814@mail.gmail.com>
	<400d33ea0910061239r4ee56deewba5d51bb154f9166@mail.gmail.com>
	<400d33ea0910061353x753efa5fl458c6c8775e1ea59@mail.gmail.com>
	<9a9942200910061415g294b448aj34ff7a710a5538f8@mail.gmail.com>
	<400d33ea0910061508g68b15107kadbbe032408685ae@mail.gmail.com>
	<400d33ea0910061531x2916ca8dqdc5df19447f3238f@mail.gmail.com>
	<9a9942200910061549y1ec423fdt74b6aebce3ac3c63@mail.gmail.com>
	<400d33ea0910061632v71b0e4eer4725dd7b9a43df09@mail.gmail.com>
	<400d33ea0910061645w2e0d620cp7246a354b380e65e@mail.gmail.com>
Message-ID: <400d33ea0910061647u1492c566v12c16ae75730a8cf@mail.gmail.com>

And I should not forget to mention that passing "true" as the last
parameter to ExecutionEngine::create makes the test program work and
finish with the output line "gv = 24601"

On Tue, Oct 6, 2009 at 6:45 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>>
>> It just occurred to me... in the case where it's failing, the
>> ExecutionEngine was trying to JIT a global, and it had never JITted
>> any functions! ?I'll work up a small test case, but I think it's
>> relevant since the thing is trying to allocate the globals with the
>> functions.
>>
>
> That was it! ?The following small test program crashes in getPointerToGlobal:
>
> #include "llvm/Module.h"
> #include "llvm/Function.h"
> #include "llvm/InlineAsm.h"
> #include "llvm/Support/IRBuilder.h"
> #include "llvm/ModuleProvider.h"
> #include "llvm/ExecutionEngine/ExecutionEngine.h"
> #include "llvm/Support/raw_os_ostream.h"
> #include "llvm/Bitcode/ReaderWriter.h"
> #include "llvm/Support/raw_ostream.h"
> #include "llvm/Target/TargetSelect.h"
> #include "llvm/ExecutionEngine/JIT.h"
>
> #include <assert.h>
>
> using namespace llvm;
>
> static raw_stdout_ostream raw_cout;
>
> int main(int argc, char** argv)
> {
> ? ? ? ?// Test JITting a variable without JITting any functions.'
> ? ? ? ?Module* mod = new Module("test", getGlobalContext());
> ? ? ? ?GlobalVariable* gv = cast<GlobalVariable>(mod->getOrInsertGlobal("TestGV",
> ? ? ? ? ? ? ? ? ? ? ? ?Type::getInt32Ty(getGlobalContext())));
> ? ? ? ?gv->setInitializer(ConstantInt::get(
> ? ? ? ? ? ? ? ?Type::getInt32Ty(getGlobalContext()), 24601));
>
> ? ? ? ?ModuleProvider* modp = new ExistingModuleProvider(mod);
> ? ? ? ?InitializeNativeTarget();
> ? ? ? ?std::string errstring;
>
> ? ? ? ?ExecutionEngine* eeng = ExecutionEngine::create(modp, false, &errstring,
> ? ? ? ? ? ? ? ? ? ? ? ?CodeGenOpt::Default, true);
> ? ? ? ?if ( eeng == NULL )
> ? ? ? ?{
> ? ? ? ? ? ? ? ?raw_cout << errstring << "\n";
> ? ? ? ? ? ? ? ?exit(-1);
> ? ? ? ?}
> ? ? ? ?raw_cout << "Fixing to get pointer to global\n";
> ? ? ? ?void* gvp = eeng->getPointerToGlobal(gv);
> ? ? ? ?raw_cout << "Got pointer to global\n";
> ? ? ? ?raw_cout << "gv = " << *((int*)gvp) << "\n";
> ? ? ? ?exit(0);
> }
>


From kennethuil at gmail.com  Tue Oct  6 19:47:39 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 6 Oct 2009 19:47:39 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
Message-ID: <400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>

On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> My front-end is sync'd with the trunk now, and working well, but it
> required some additional functions exposed in the C bindings. ?I
> hereby submit them for review and approval for inclusion in the trunk.
>

LLVMGetAttribute had a bug in it.  Here's the revised version of the patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbindings.patch
Type: text/x-patch
Size: 7270 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091006/91de8d57/attachment.bin 

From tynarex at gmail.com  Tue Oct  6 21:33:29 2009
From: tynarex at gmail.com (Wenhao Jia)
Date: Tue, 6 Oct 2009 22:33:29 -0400
Subject: [LLVMdev] Use LoopInfo in a non-pass class such as
	ProfileInfoLoader?
Message-ID: <2015205e0910061933m77ace1c0h429eb166449830ff@mail.gmail.com>

Hi everyone,

I'm adding loop profiling to LLVM built-in profiler. I'm just
wondering in a class that's not a pass, such as ProfileInfoLoader, how
can I get information produced by passes such as LoopInfo and
DominatorTree?

In other words, ProfileInfoLoader is not a pass, so it can't call
AnalysisUsage::addRequired and AnalysisUsage::getAnalysisUsage
directly. Then how can it know if an arbitrary basic block is a loop
header using information/classes/methods available to it?

Thanks a lot!

Wenhao Jia

From viridia at gmail.com  Tue Oct  6 23:05:12 2009
From: viridia at gmail.com (Talin)
Date: Tue, 06 Oct 2009 21:05:12 -0700
Subject: [LLVMdev] Internalize pass
In-Reply-To: <9a9942200910031047v682230e7oadf27713b53b326d@mail.gmail.com>
References: <d1b71f830909300006vb50e012r15b08610acc0a6d3@mail.gmail.com>
	<63C7823F-ACAD-4704-ABB9-4990967C4C0E@apple.com>
	<4AC6DE11.4090309@gmail.com>
	<9a9942200910031047v682230e7oadf27713b53b326d@mail.gmail.com>
Message-ID: <4ACC1378.8090101@gmail.com>

Reid Kleckner wrote:
> Sounds like LLVM thinks the calling conventions or declarations are
> mismatched.  See:
> http://llvm.org/docs/FAQ.html#callconvwrong
>
>   
BTW, I'm still completely stumped on this issue, and I've put it aside 
to work on other things. But it would be nice to re-enable internalize :)
> Reid
>
> On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote:
>   
>> Well, after some investigation I have a few more clues as to what is
>> going on.
>>
>> I have a module which contains a call to an external native function.
>> This native function lives in a static library, and there is an external
>> declaration for it in the module.
>>
>> I find that I can run "llvm-ld -disable-opts -native -l mylibrary
>> test.bc" and it works fine. That is, llvm-ld is able to generate a
>> native object file, and link it against the static library with no problem.
>>
>> However, if I remove the "-disable-opts" line, it seems to replace the
>> call to the native function with "unreachable". I'm not 100% certain of
>> this, but if I replace the native function with a non-native function
>> that does something similar, then it seems to work ok.
>>
>> Chris Lattner wrote:
>>     
>>> On Sep 30, 2009, at 12:06 AM, Talin wrote:
>>>
>>>       
>>>> I'm playing around with different combinations of LTO passes, and
>>>> I've run into a strange problem:
>>>>
>>>> I have a 'main' function that looks like this:
>>>>
>>>> define i32
>>>> @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*
>>>> %args) {
>>>> entry:
>>>>   call void @llvm.dbg.func.start(metadata !0)
>>>>   call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata !1)
>>>>   %integerLimitsTest = call { } @integerLimitsTest() ; <{ }> [#uses=0]
>>>>   call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>>>   %integerToStringTest = call { } @integerToStringTest() ; <{ }>
>>>> [#uses=0]
>>>>   call void @llvm.dbg.stoppoint(i32 4, i32 9, metadata !1)
>>>>   call void @llvm.dbg.region.end(metadata !0)
>>>>   ret i32 0
>>>> }
>>>>
>>>> However, when I add an internalize pass before the other LTO passes,
>>>> the 'main' function turns into this:
>>>>
>>>> define i32 @main(i32, i8** nocapture) nounwind readnone {
>>>> entry:
>>>>   tail call void @llvm.dbg.func.start(metadata !0)
>>>>   tail call void @llvm.dbg.stoppoint(i32 3, i32 21, metadata !1)
>>>>   unreachable
>>>> }
>>>>
>>>> The thing is, there's nothing particularly special or interesting
>>>> about the functions being called from main().
>>>>         
>>> This is likely to not be due to internalize itself.  Internalize marks
>>> functions "internal", which allows other interprocedural optimizers to
>>> have more freedom to change their interfaces etc.  The likely problem
>>> here is that you are calling something from 'main' with mismatching
>>> calling conventions or something like that.  It is hard to say without
>>> a full testcase.
>>>
>>> -Chris
>>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
>
>   


From gohman at apple.com  Tue Oct  6 23:35:28 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 6 Oct 2009 21:35:28 -0700
Subject: [LLVMdev] What opt pass attempts implements this optimization?
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB584A3DB@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB584A3DB@ssanexmb2.amd.com>
Message-ID: <4513CCDE-9A1A-4C35-9A92-999F107AD424@apple.com>


On Oct 6, 2009, at 4:28 PM, Villmow, Micah wrote:

> I have a very simple kernel that is generating very very bad code.
>
> The basic kernel pseudo-code is as follows:
> forloop(1 to n) {
>   forloop(0 to j) {
>   A
> }
> B
> }
> C
>
> It is generating very ugly and inefficient code for a vector system  
> similar to the following pseudo-code:
> if (n > 1) {
>   if (j) {
>                 forloop(1 to n) {
>                                 forloop(0 to j) {
>                                 A
>                                 }
>                                 B
>                 }
>                C
>    } else {
>                 forloop(1 to n) {
>                                 B
>                 }
>                 C
>    }
> } else {
> C
> }

It's possible that there's something going on with loop unswitching  
here. Do you
have a testcase which demonstrates this?

Dan


From jaykang10 at imrc.kist.re.kr  Wed Oct  7 01:22:26 2009
From: jaykang10 at imrc.kist.re.kr (Jin Gu Kang)
Date: Wed, 7 Oct 2009 15:22:26 +0900
Subject: [LLVMdev] llvm-gcc configure options for ARM target at llvm-gcc
	build time
Message-ID: <3E94D039A2B82544B3E7D48F924B0B25372197643D@base.imrc.kist.re.kr>

Dear LLVM members.

I am building llvm-gcc in version 2.5 for ARM target.

I used command line option as following:

>../src/configure --prefix=/home/jaykang10/Projects/LLVM/front_end_test/bin/ --enable-languages=c,c++ --enable-checking --enable-llvm=/home/jaykang10/Projects/LLVM/bin/ --disable-bootstrap --disable-multilib --target=arm-eabi

And I got a error message as following:
...
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build -I../../src/gcc/../include -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber -I../libdecnumber -I/home/jaykang10/Projects/LLVM/bin//include -I/home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/include -DENABLE_LLVM -I/home/jaykang10/HardDisk2/Projects/LLVM/bin/include -DARM_COFF_KIST -DARM_KIST_BUG_FIX -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   -o build/gencondmd.o build/gencondmd.c
../../src/gcc/config/arm/arm.md:4788: error: ?MACHO_DYNAMIC_NO_PIC_P? undeclared here (not in a function)
../../src/gcc/config/arm/arm.md:4789: warning: missing initializer
../../src/gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[15].value?)
../../src/gcc/config/arm/arm.md:4703: warning: missing initializer
../../src/gcc/config/arm/arm.md:4703: warning: (near initialization for ?insn_conditions[56].value?)
../../src/gcc/config/arm/arm.md:4789: warning: missing initializer
../../src/gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[86].value?)
...

To use "MACHO_DYNAMIC_NO_PIC_P", I guess that --target option have to include -darwin

In gcc/config.gcc file
...
# Common parts for widely ported systems.
case ${target} in
*-*-darwin*)
  tm_file="${tm_file} darwin.h"
...

At llvm-gcc build time, I would like to know configure option for ARM target.
and I want to know whether llvm-gcc have bitcode's difference between -darwin and other configure options.
(ex: -eabi, -elf, etc...)

Thanks

Best regards,
Jin-Gu Kang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/fc25e9dc/attachment.html 

From jaykang10 at imrc.kist.re.kr  Wed Oct  7 04:18:38 2009
From: jaykang10 at imrc.kist.re.kr (Jin Gu Kang)
Date: Wed, 7 Oct 2009 18:18:38 +0900
Subject: [LLVMdev] llvm-gcc configure options for ARM target at llvm-gcc
	build time
In-Reply-To: <3E94D039A2B82544B3E7D48F924B0B25372197643D@base.imrc.kist.re.kr>
References: <3E94D039A2B82544B3E7D48F924B0B25372197643D@base.imrc.kist.re.kr>
Message-ID: <3E94D039A2B82544B3E7D48F924B0B253721976440@base.imrc.kist.re.kr>

I have more questions.

Does the llvm-gcc need 'target.md' file at build time?
and
Does the llvm-gcc use generated functions and data structure from 'target.md' to make bitcode?

void
tree_rest_of_compilation (tree fndecl)
{
...
#ifdef ENABLE_LLVM
  execute_pass_list(all_extra_lowering_passes);
  llvm_emit_code_for_current_function(fndecl);
#else
  execute_pass_list (all_passes);
#endif
...
}
I wonder that llvm-gcc needs rtl related code to make bitcode.

Thanks

Best regards,
Jin-Gu Kang

________________________________
From: Jin Gu Kang
Sent: Wednesday, October 07, 2009 3:22 PM
To: llvmdev at cs.uiuc.edu
Subject: llvm-gcc configure options for ARM target at llvm-gcc build time

Dear LLVM members.

I am building llvm-gcc in version 2.5 for ARM target.

I used command line option as following:

>../src/configure --prefix=/home/jaykang10/Projects/LLVM/front_end_test/bin/ --enable-languages=c,c++ --enable-checking --enable-llvm=/home/jaykang10/Projects/LLVM/bin/ --disable-bootstrap --disable-multilib --target=arm-eabi

And I got a error message as following:
...
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build -I../../src/gcc/../include -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber -I../libdecnumber -I/home/jaykang10/Projects/LLVM/bin//include -I/home/jaykang10/HardDisk2/Projects/LLVM/src/llvm-2.5/include -DENABLE_LLVM -I/home/jaykang10/HardDisk2/Projects/LLVM/bin/include -DARM_COFF_KIST -DARM_KIST_BUG_FIX -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   -o build/gencondmd.o build/gencondmd.c
../../src/gcc/config/arm/arm.md:4788: error: ?MACHO_DYNAMIC_NO_PIC_P? undeclared here (not in a function)
../../src/gcc/config/arm/arm.md:4789: warning: missing initializer
../../src/gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[15].value?)
../../src/gcc/config/arm/arm.md:4703: warning: missing initializer
../../src/gcc/config/arm/arm.md:4703: warning: (near initialization for ?insn_conditions[56].value?)
../../src/gcc/config/arm/arm.md:4789: warning: missing initializer
../../src/gcc/config/arm/arm.md:4789: warning: (near initialization for ?insn_conditions[86].value?)
...

To use "MACHO_DYNAMIC_NO_PIC_P", I guess that --target option have to include -darwin

In gcc/config.gcc file
...
# Common parts for widely ported systems.
case ${target} in
*-*-darwin*)
  tm_file="${tm_file} darwin.h"
...

At llvm-gcc build time, I would like to know configure option for ARM target.
and I want to know whether llvm-gcc have bitcode's difference between -darwin and other configure options.
(ex: -eabi, -elf, etc...)

Thanks

Best regards,
Jin-Gu Kang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/5d638fe8/attachment-0001.html 

From anton at korobeynikov.info  Wed Oct  7 04:51:44 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 7 Oct 2009 13:51:44 +0400
Subject: [LLVMdev] llvm-gcc configure options for ARM target at llvm-gcc
	build time
In-Reply-To: <3E94D039A2B82544B3E7D48F924B0B25372197643D@base.imrc.kist.re.kr>
References: <3E94D039A2B82544B3E7D48F924B0B25372197643D@base.imrc.kist.re.kr>
Message-ID: <b087fca00910070251o48afcce5pc34cd0630f30895a@mail.gmail.com>

> I am building llvm-gcc in version 2.5 for ARM target.
Consider using 2.6 release or even SVN top of the tree. The problem
was fixed there.

> and I want to know whether llvm-gcc have bitcode's difference between
> -darwin and other configure options.
> (ex: -eabi, -elf, etc...)
Yes, there are bitcode differences due to different set of defines,
different ABIs, etc.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From pietreka at gmail.com  Wed Oct  7 06:49:58 2009
From: pietreka at gmail.com (Artur Pietrek)
Date: Wed, 7 Oct 2009 13:49:58 +0200
Subject: [LLVMdev] TableGen question - how to split a 64bit operation to
	two 32bit
In-Reply-To: <223225FA-95DE-47C0-B5F9-EA61827E16B9@apple.com>
References: <d50b8be20910060510n7df87db1lc3fe574f5f17e84d@mail.gmail.com>
	<223225FA-95DE-47C0-B5F9-EA61827E16B9@apple.com>
Message-ID: <d50b8be20910070449k1588c995w87a7fc5ba3f10015@mail.gmail.com>

Hi Jim,

On Tue, Oct 6, 2009 at 5:39 PM, Jim Grosbach <grosbach at apple.com> wrote:

> Hi Artur,
>
> The Thumb2 target (in lib/Targets/ARM/ARMInstrThumb2.td) materializes a
> 32-bit constant by a two-instruction sequence to load the low and high
> half-words. It's not pretty, but it works. The pattern is at the bottom of
> the file.
>
> Regards,
> -Jim


Wow, somehow I've missed that when I was looking in the source. Thanks a
lot.

Artur



> On Oct 6, 2009, at 5:10 AM, Artur Pietrek wrote:
>
>  Hi all,
>> I'm working on my own backend for a custom CPU. I have defined paired
>> registers for 64bit operations, however to set a 64bit paired register with
>> 64bit immediate I have to set each register in that pair separately with the
>> higher and the lower 32bits of the immediate.
>> Could anyone give me an advice how to describe it in *InstructionInfo.td
>> or point me to something similar in the LLVM source code? (I was looking for
>> it but couldn't find it)
>>
>> Thanks,
>> Artur
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/a0649379/attachment.html 

From kennethuil at gmail.com  Wed Oct  7 09:31:45 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Wed, 7 Oct 2009 09:31:45 -0500
Subject: [LLVMdev] InitializeNativeTarget
Message-ID: <400d33ea0910070731o486e787ahb3fd7636b7ae8c9a@mail.gmail.com>

It seems that a client application needs to call
InitializeNativeTarget or LLVMInitializeNativeTarget before doing any
JITting.  Unfortunately, LLVMInitializeNativeTarget is defined static
inline and does not appear in the .a files; thus a client not written
in C or C++ trying to JIT cannot link to the library and call
LLVMInitializeNativeTarget that way.

It can call a target-specific library function such as
LLVMInitializeX86Target, but this is obviously not portable.

From luoyonggang at gmail.com  Wed Oct  7 09:57:41 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Wed, 7 Oct 2009 22:57:41 +0800
Subject: [LLVMdev] Hi, everyone, fail on building c-index-test
In-Reply-To: <50EF0731-3436-4F53-B8D5-2347F97EA359@apple.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com> 
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
	<806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com> 
	<50EF0731-3436-4F53-B8D5-2347F97EA359@apple.com>
Message-ID: <806065d90910070757y4d9070echc408cc822760fb95@mail.gmail.com>

>
> I've committed my suggested fix. There's no point in setting the
> LINKER_LANGUAGE property of every LLVM library, because CMake figures out
> the right language based on the file extensions of the source files.

Yes, CMake figures out the *right language* based on the file extensions of
the source files.
But, llvm is based on *C++*
for example, if you create a application just containing *C *extension
files,
but using llvm as the midware, then CMake system *must *auto  recognize
the LINKER_LANGUAGE as CXX, but not C. Even all source files in this project
is C extension.

Now, it's using a strange hack, just

set_target_properties(c-index-test
  PROPERTIES
  LINKER_LANGUAGE CXX)
It's not reasonable, because it's not because of  c-index-test.c lead the
LINKER_LANGUAGE  to be CXX
but llvm make this happened, so it's shouldn't be placed at
c-index-test.c/CMakeLists.txt
*and should be placed at *
AddLLVM.cmake
That's means, every  *new project(OR executable)* using LLVM as the
dependent,
then  then
LINKER_LANGUAGE   must be set to CXX in an auto way,
but not set it manually.


-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/0f52982b/attachment.html 

From Ken.Dyck at onsemi.com  Wed Oct  7 10:21:08 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Wed, 7 Oct 2009 08:21:08 -0700
Subject: [LLVMdev] VLIW Scheduling Redux
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B277476B83D5@NAMAIL.ad.onsemi.com>

Have there been any developments in the codegen/scheduling
infrastructure that would invalidate the advice given in this thread
from September 2005?

http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html

-Ken


From dgregor at apple.com  Wed Oct  7 10:32:32 2009
From: dgregor at apple.com (Douglas Gregor)
Date: Wed, 7 Oct 2009 08:32:32 -0700
Subject: [LLVMdev] Hi, everyone, fail on building c-index-test
In-Reply-To: <806065d90910070757y4d9070echc408cc822760fb95@mail.gmail.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
	<806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com>
	<50EF0731-3436-4F53-B8D5-2347F97EA359@apple.com>
	<806065d90910070757y4d9070echc408cc822760fb95@mail.gmail.com>
Message-ID: <E723FED7-3680-4F93-8056-194CCE5B2F2F@apple.com>


On Oct 7, 2009, at 7:57 AM, ???(Yonggang Luo) wrote:

> I've committed my suggested fix. There's no point in setting the  
> LINKER_LANGUAGE property of every LLVM library, because CMake  
> figures out the right language based on the file extensions of the  
> source files.
> Yes, CMake figures out the right language based on the file  
> extensions of the source files.
> But, llvm is based on C++

That does not mean that every library or application built within the  
LLVM tree must be linked as C++.

> for example, if you create a application just containing C extension  
> files,
> but using llvm as the midware, then CMake system must auto   
> recognize the LINKER_LANGUAGE as CXX, but not C. Even all source  
> files in this project is C extension.
>
> Now, it's using a strange hack, just
>
> set_target_properties(c-index-test
>   PROPERTIES
>   LINKER_LANGUAGE CXX)
> It's not reasonable, because it's not because of  c-index-test.c  
> lead the
> LINKER_LANGUAGE  to be CXX
> but llvm make this happened, so it's shouldn't be placed at
> c-index-test.c/CMakeLists.txt
> and should be placed at
> AddLLVM.cmake
> That's means, every  new project(OR executable) using LLVM as the  
> dependent,
> then  then
> LINKER_LANGUAGE   must be set to CXX in an auto way,
> but not set it manually.


There is only one place in the entire LLVM + Clang source tree where  
we need to explicitly set the linker language to C++. There is no  
point in trying to generalize when there is only one example, and we  
don't know if the next target we add that has only .c files will  
require C++ linkage or not. If it does, we can decide to generalize  
then (or not).

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/76c04306/attachment.html 

From luoyonggang at gmail.com  Wed Oct  7 10:32:43 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Wed, 7 Oct 2009 23:32:43 +0800
Subject: [LLVMdev] patch for CIndex linakge error on Mingw,
	set the proper 	LINKER_LANGUAGE for CIndex and c-index-test
Message-ID: <806065d90910070832r7815f99cl1028d709a6e5e032@mail.gmail.com>

\tools\clang\tools\CIndex && D:\Tools\Building\cmake\bin\cmake.exe -E
cmake_link_script CMakeFiles\CIndex.dir\link.txt --verbose=1
D:\Tools\Building\gcc\bin\g++.exe    -shared -o
..\..\..\..\bin\libCIndex.dll
-Wl,--out-implib,..\..\..\..\lib\libCIndex.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
CMakeFiles\CIndex.dir\CIndex.cpp.obj ..\..\..\..\lib\libLLVMMC.a
..\..\..\..\lib\libLLVMSupport.a ..\..\..\..\lib\libLLVMSystem.a
..\..\..\..\lib\libclangFrontend.a ..\..\..\..\lib\libclangIndex.a
..\..\..\..\lib\libclangSema.a ..\..\..\..\lib\libclangAST.a
..\..\..\..\lib\libclangLex.a ..\..\..\..\lib\libclangBasic.a -lgcc_eh
-lgcc_eh -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32
..\..\..\..\lib\libclangFrontend.a(ASTUnit.cpp.obj):ASTUnit.cpp:(.text$_ZN5clang13SourceManagerC1Ev[clang::SourceManager::SourceManager()]+0xf):
undefined reference to `llvm::BumpPtrAllocator::DefaultSlabAllocator'
..\..\..\..\lib\libclangFrontend.a(ASTUnit.cpp.obj):ASTUnit.cpp:(.text$_ZN5clang13SourceManagerC1Ev[clang::SourceManager::SourceManager()]+0x27):
undefined reference to `llvm::BumpPtrAllocator::BumpPtrAllocator(unsigned
int, unsigned int, llvm::SlabAllocator&)'
..\..\..\..\lib\libclangFrontend.a(ASTUnit.cpp.obj):ASTUnit.cpp:(.text$_ZN5clang13SourceManagerC1Ev[clang::SourceManager::SourceManager()]+0x17f):
undefined reference to `llvm::BumpPtrAllocator::~BumpPtrAllocator()'
..\..\..\..\lib\libclangFrontend.a(PCHReader.cpp.obj):PCHReader.cpp:(.text+0x61ed):
undefined reference to `llvm::MemoryBuffer::getMemBuffer(char const*, char
const*, char const*)'
..\..\..\..\lib\libclangFrontend.a(PCHReader.cpp.obj):PCHReader.cpp:(.text+0x79d0):
undefined reference to `llvm::MemoryBuffer::getSTDIN()'
..\..\..\..\lib\libclangFrontend.a(PCHReader.cpp.obj):PCHReader.cpp:(.text+0x7a11):
undefined reference to `llvm::MemoryBuffer::getFile(char const*,
std::string*, long long)'
..\..\..\..\lib\libclangFrontend.a(PCHReader.cpp.obj):PCHReader.cpp:(.text+0x860c):
undefined refer
.......
And more


These two patch should apply at the same time.


It's not a good idea to direct set the LINKER_LANGUAGE
at CMakeLists.txt files.

-- 
        ??
?
???
Yours
   sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/8f200505/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm-AddLLvm-Cmake-patch-for-Dynamic-linkage-Library.patch
Type: application/octet-stream
Size: 2707 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/8f200505/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CIndex-linkage-patch.patch
Type: application/octet-stream
Size: 853 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/8f200505/attachment-0001.obj 

From howarth at bromo.med.uc.edu  Wed Oct  7 11:12:19 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Wed, 7 Oct 2009 12:12:19 -0400
Subject: [LLVMdev] llvm LTO SPEC2000 results?
Message-ID: <20091007161219.GA18608@bromo.med.uc.edu>

   Are there any results for the SPEC2000 benchmarks
using llvm with and without LTO? It would be interesting
to know how the current LTO in llvm compares to the
results being seen in current gcc trunk with their
LTO...

http://gcc.gnu.org/ml/gcc/2009-10/msg00155.html

It would appear that the gcc LTO implementation
is finally showing results (although with a lot
of wrong code results). I assume we really don't
have a functional -fwhole-program in llvm-gcc-4.2
but do we have one in clang?
                 Jack

From kmrc87 at gmail.com  Wed Oct  7 11:25:46 2009
From: kmrc87 at gmail.com (Ravi Chandhran)
Date: Wed, 7 Oct 2009 21:55:46 +0530
Subject: [LLVMdev] Linking library files using llvmc
Message-ID: <c10888c30910070925u4f2991dfi7b9bea331786c00a@mail.gmail.com>

I was using llvmc along with the -opt option to perform static analyzes in
some of the commonly used programs like bzip2, gzip, grep etc. I found that
when llvmc is used to link libraries (.a or .so files) using the -l option
it passes the library files to the linker ( for me it was llvm-gcc itself)
but changes the order in which it was given to llvmc.

Eg: the command: " llvmc -o grep.o -v  -opt grep.o -L../ -lgreputils "  is
executed as

        llvm-gcc -L../ -lgreputils grep.o -o grep

Note that the library files are pushed to front in llvm-gcc even though it
was given as the last option to llvmc. Due to this llvm-gcc is not able to
resolve the calls made in grep.o to the functions contained in greputils
library.  looks like a bug in llvmc.  The llvm version that I am using is
2.6 and the llvm-gcc version  is  4.2.1.

-Ravichandhran Kandhadai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/fd94a897/attachment.html 

From devang.patel at gmail.com  Wed Oct  7 11:50:56 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Wed, 7 Oct 2009 09:50:56 -0700
Subject: [LLVMdev] DebugFactory
In-Reply-To: <d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>
References: <4AB87938.6080807@gmail.com>
	<352a1fb20909220921h7577d473v90c9c61c05de61ca@mail.gmail.com>
	<352a1fb20909220921w5c61511am5712e49a3a3b6cfa@mail.gmail.com>
	<d1b71f830909221649l4e2233c1h215d88529ea8ee2c@mail.gmail.com>
	<58C4E46A-95EC-40E2-9E1F-4E9E09C8B699@apple.com>
	<d1b71f830909231427r51de6aeek53d4aa78abcd7122@mail.gmail.com>
	<352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>
	<d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>
Message-ID: <352a1fb20910070950r4fb8acc0r69682c4a20c50226@mail.gmail.com>

On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote:
> Here is a patch that does just that.

This does not work. I'm getting

llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function
?llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType,
llvm::DICompileUnit)?:
/Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225:
error: call of overloaded ?CreateDerivedType(unsigned int&,
llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int,
int, int, int, llvm::DIType&)? is ambiguous
llvm/include/llvm/Analysis/DebugInfo.h:530: note: candidates are:
llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
llvm::DIDescriptor, llvm::StringRef, llvm::DICompileUnit, unsigned
int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType)
llvm/include/llvm/Analysis/DebugInfo.h:540: note:
llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
llvm::DIDescriptor, const std::string&, llvm::DICompileUnit, unsigned
int, llvm::Constant*, llvm::Constant*, llvm::Constant*, unsigned int,
llvm::DIType)

-
Devang


From baldrick at free.fr  Wed Oct  7 11:57:35 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 07 Oct 2009 18:57:35 +0200
Subject: [LLVMdev] llvm LTO SPEC2000 results?
In-Reply-To: <20091007161219.GA18608@bromo.med.uc.edu>
References: <20091007161219.GA18608@bromo.med.uc.edu>
Message-ID: <4ACCC87F.2020105@free.fr>

Hi Jack,

> It would appear that the gcc LTO implementation
> is finally showing results (although with a lot
> of wrong code results). I assume we really don't
> have a functional -fwhole-program in llvm-gcc-4.2
> but do we have one in clang?

it's been possible to do the equivalent of -fwhole-program
for ages in LLVM, you just have to run some LLVM tools by
hand or use the gold plugin.  I never did it on SPEC (I don't
have SPEC) but for some scientific computation stuff I have here
I saw a 10% speed up (more or less) using whole program lto.

Ciao,

Duncan.

From Micah.Villmow at amd.com  Wed Oct  7 13:02:56 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Wed, 7 Oct 2009 11:02:56 -0700
Subject: [LLVMdev] What opt pass attempts implements this optimization?
In-Reply-To: <4513CCDE-9A1A-4C35-9A92-999F107AD424@apple.com>
References: <493720826E33B1459E7F5C253E6D4BB584A3DB@ssanexmb2.amd.com>
	<4513CCDE-9A1A-4C35-9A92-999F107AD424@apple.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D79D2@ssanexmb2.amd.com>

Dan,
 After I sent out this email a co-worker pointed me to LoopUnswitch
optimization as being a possible culprit. We set it to zero and it no
longer generates all this code. I've attached optimized bc and
unoptimized bc for this specific example.

Micah

> -----Original Message-----
> From: Dan Gohman [mailto:gohman at apple.com]
> Sent: Tuesday, October 06, 2009 9:35 PM
> To: Villmow, Micah
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] What opt pass attempts implements this
> optimization?
> 
> 
> On Oct 6, 2009, at 4:28 PM, Villmow, Micah wrote:
> 
> > I have a very simple kernel that is generating very very bad code.
> >
> > The basic kernel pseudo-code is as follows:
> > forloop(1 to n) {
> >   forloop(0 to j) {
> >   A
> > }
> > B
> > }
> > C
> >
> > It is generating very ugly and inefficient code for a vector system
> > similar to the following pseudo-code:
> > if (n > 1) {
> >   if (j) {
> >                 forloop(1 to n) {
> >                                 forloop(0 to j) {
> >                                 A
> >                                 }
> >                                 B
> >                 }
> >                C
> >    } else {
> >                 forloop(1 to n) {
> >                                 B
> >                 }
> >                 C
> >    }
> > } else {
> > C
> > }
> 
> It's possible that there's something going on with loop unswitching
> here. Do you
> have a testcase which demonstrates this?
> 
> Dan
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AESEncryptDecrypt-opt.bc
Type: application/octet-stream
Size: 26732 bytes
Desc: AESEncryptDecrypt-opt.bc
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/15ba61af/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AESEncryptDecrypt.bc
Type: application/octet-stream
Size: 7416 bytes
Desc: AESEncryptDecrypt.bc
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/15ba61af/attachment-0001.obj 

From Micah.Villmow at amd.com  Wed Oct  7 13:20:05 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Wed, 7 Oct 2009 11:20:05 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>

Is there a current way to specify that an instruction or function call
cannot be duplicated and thus any optimizations that might want to
duplicate this instruction would fail?

 

The problem deals with barrier in OpenCL 1.0. One of the conditions of
using barrier is that if a barrier exists inside of control flow, every
thread in a work-group must execute the barrier instruction(6.11.9). 

 

However, in this simple CL code:
#pragma OPENCL EXTENSION cl_khr_local_int32_base_atomics: enable

#pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics: enable

__kernel void  

KMeansMapReduceAtomic(const int  num_attributes,

                      const int  num_objects,

                      __global int* delta_d

                      ) 

{

                __local int clusterCount[256];

                __local int sTemp[1];  // amd opencl needed this to be
an array

    const unsigned int point_id = get_local_id(0);

   int  index = 0;

   int i, addr;

   int xx = get_local_id(0);

   clusterCount[xx] = 0;

   if(get_local_id(0) == 0){

     sTemp[0] = 0; //sTemp is for prefix sum

     }

   barrier(CLK_LOCAL_MEM_FENCE);

   int idWithinCluster = 300; // anthing other then zero

   if (point_id < num_objects) {

    idWithinCluster = atom_add(&clusterCount

                               [index],1);

                }

                  barrier(CLK_LOCAL_MEM_FENCE);

int numMembers = 2; 

                if(idWithinCluster == 0)                 {

                                clusterCount[index] =
atom_add(&sTemp[0], numMembers);//This holds the prefix offset

                }

   delta_d[xx] = clusterCount[index];

}

 

produces bitcode file which has 3 barriers.

 

The problem is now that the second if/barrier pair:

if (point_id < num_objects) {

    idWithinCluster = atom_add(&clusterCount

                               [index],1);

                }

                  barrier(CLK_LOCAL_MEM_FENCE);

 

 

is transformed into flow control equivalent to :

if (point_id >= num_objects) {

  barrier(CLK_LOCAL_MEM_FENCE);

} else {

    idWithinCluster = atom_add(&clusterCount

                               [index],1);

  barrier(CLK_LOCAL_MEM_FENCE);

}

 

which violates opencl, which can cause undefined behavior on the
underlying hardware, as each barrier is unique.  

 

So we want to disable all optimizations around barrier instructions, but
not in other cases when no barrier instruction exists. One way to do
this is to mark an instruction as not being copyable, but is there a
method of doing this in LLVM?

 

Also, this barrier does not map to llvm.barrier because llvm.barrier
only seems to worry about memory operations and not synchronization
between threads.

 

Thanks for any help,

Micah

                

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/5cebd323/attachment.html 

From dalej at apple.com  Wed Oct  7 13:22:46 2009
From: dalej at apple.com (Dale Johannesen)
Date: Wed, 7 Oct 2009 11:22:46 -0700
Subject: [LLVMdev] llvm LTO SPEC2000 results?
In-Reply-To: <20091007161219.GA18608@bromo.med.uc.edu>
References: <20091007161219.GA18608@bromo.med.uc.edu>
Message-ID: <823F47BC-76C0-4C1D-BF9B-727D4E1DED1B@apple.com>

I don't know of anyone focusing on better SPEC numbers, although those  
who have access run a subset primarily as a regression test.
On Darwin, llvm-gcc-4.2 -O4 will get interprocedural optimizations;  
this makes the compiler emit LLVM bitcode and the linker invoke the  
interprocedural optimizer.   You might need to have SnowLeopard.  The  
linker dependency means this is not very portable; there is something  
called the LLVM gold plugin that is aimed at doing the same thing on  
Linux, but I don't know how well it works.

On Oct 7, 2009, at 9:12 AMPDT, Jack Howarth wrote:

>   Are there any results for the SPEC2000 benchmarks
> using llvm with and without LTO? It would be interesting
> to know how the current LTO in llvm compares to the
> results being seen in current gcc trunk with their
> LTO...
>
> http://gcc.gnu.org/ml/gcc/2009-10/msg00155.html
>
> It would appear that the gcc LTO implementation
> is finally showing results (although with a lot
> of wrong code results). I assume we really don't
> have a functional -fwhole-program in llvm-gcc-4.2
> but do we have one in clang?
>                 Jack
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From Dr.Graef at t-online.de  Wed Oct  7 13:36:24 2009
From: Dr.Graef at t-online.de (Albert Graef)
Date: Wed, 07 Oct 2009 20:36:24 +0200
Subject: [LLVMdev] InitializeNativeTarget
In-Reply-To: <400d33ea0910070731o486e787ahb3fd7636b7ae8c9a@mail.gmail.com>
References: <400d33ea0910070731o486e787ahb3fd7636b7ae8c9a@mail.gmail.com>
Message-ID: <4ACCDFA8.3000409@t-online.de>

Kenneth Uildriks wrote:
> It seems that a client application needs to call
> InitializeNativeTarget or LLVMInitializeNativeTarget before doing any
> JITting.  Unfortunately, LLVMInitializeNativeTarget is defined static
> inline and does not appear in the .a files; thus a client not written
> in C or C++ trying to JIT cannot link to the library and call
> LLVMInitializeNativeTarget that way.

Yes, so you'll need to add a little C++ module to your wrapper that does
the necessary initializations and is callable from your target language.

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

From DevOmem at web.de  Wed Oct  7 14:02:53 2009
From: DevOmem at web.de (DevOllvm)
Date: Wed, 7 Oct 2009 12:02:53 -0700 (PDT)
Subject: [LLVMdev] MinGW/MSVC++ uses different ABI for sret
In-Reply-To: <87zl8iijen.fsf@telefonica.net>
References: <878wg2k8hk.fsf@telefonica.net>
	<f5aa3e9b0909251650y5e83d19cs334385e531b7a68c@mail.gmail.com>
	<874oqqk03z.fsf@telefonica.net> <87zl8iijen.fsf@telefonica.net>
Message-ID: <25792485.post@talk.nabble.com>


Hi,

is there any news about this problem?
How hart it will be to resolve this compatibility problem with Visual Studio
functions ?

This is really great problem for my project with should call may different
function compiled by Visual Studio!!!

Here is also problem that is looking similar.
http://llvm.org/bugs/show_bug.cgi?id=5046

-- 
View this message in context: http://www.nabble.com/MinGW-MSVC%2B%2B-uses-different-ABI-for-sret-tp25619776p25792485.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From ofv at wanadoo.es  Wed Oct  7 16:13:03 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Wed, 07 Oct 2009 23:13:03 +0200
Subject: [LLVMdev] MinGW/MSVC++ uses different ABI for sret
References: <878wg2k8hk.fsf@telefonica.net>
	<f5aa3e9b0909251650y5e83d19cs334385e531b7a68c@mail.gmail.com>
	<874oqqk03z.fsf@telefonica.net> <87zl8iijen.fsf@telefonica.net>
	<25792485.post@talk.nabble.com>
Message-ID: <8763aqdi1s.fsf@telefonica.net>

DevOllvm <DevOmem at web.de> writes:

> Hi,
>
> is there any news about this problem?
> How hart it will be to resolve this compatibility problem with Visual Studio
> functions ?

Fixing the sret issue is easy: LLVM shall simply ignore it for
*-pc-win32 targets. You can workaround the problem on your compiler
by not using the sret attribute. That's what I did.

Fixing the problem with C++ non-POD classes as function arguments will
be much harder to fix. Most probably it will require to extend LLVM to
accept and call copy constructors and destructors on `byval' arguments.

> This is really great problem for my project with should call may different
> function compiled by Visual Studio!!!
>
> Here is also problem that is looking similar.
> http://llvm.org/bugs/show_bug.cgi?id=5046

The bug id about sret is 5058. The other about C++ non-POD function
arguments is 5064. Please note that the workaround suggested there is
not correct: apart from the other potential issues I mention, it is
doing exactly the same as `byval' does now.

-- 
?scar


From shreyas76 at gmail.com  Wed Oct  7 16:57:39 2009
From: shreyas76 at gmail.com (shreyas krishnan)
Date: Wed, 7 Oct 2009 14:57:39 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
Message-ID: <24389fb30910071457k385532e1u257e0c50f6fbc63f@mail.gmail.com>

If I may -an unrelated question perhaps- can clang in trunk compile
this CL program with the 2  OPENCL EXTENSION and keyword __kernel?

thanks
shrey



On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Is there a current way to specify that an instruction or function call
> cannot be duplicated and thus any optimizations that might want to duplicate
> this instruction would fail?
>
>
>
> The problem deals with barrier in OpenCL 1.0. One of the conditions of using
> barrier is that if a barrier exists inside of control flow, every thread in
> a work-group must execute the barrier instruction(6.11.9).
>
>
>
> However, in this simple CL code:
> #pragma OPENCL EXTENSION cl_khr_local_int32_base_atomics: enable
>
> #pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics: enable
>
> __kernel void
>
> KMeansMapReduceAtomic(const int? num_attributes,
>
> ????????????????????? const int? num_objects,
>
> ??????????? ??????????__global int* delta_d
>
> ????????????????????? )
>
> {
>
> ??????????????? __local int clusterCount[256];
>
> ??????????????? __local int sTemp[1];? // amd opencl needed this to be an
> array
>
> ? ??const unsigned int point_id = get_local_id(0);
>
> ?? int? index = 0;
>
> ?? int i, addr;
>
> ?? int xx = get_local_id(0);
>
> ?? clusterCount[xx] = 0;
>
> ?? if(get_local_id(0) == 0){
>
> ???? sTemp[0] = 0; //sTemp is for prefix sum
>
> ???? }
>
> ?? barrier(CLK_LOCAL_MEM_FENCE);
>
> ?? int idWithinCluster = 300; // anthing other then zero
>
> ?? if (point_id < num_objects) {
>
> ??? idWithinCluster = atom_add(&clusterCount
>
> ?????????????????????????????? [index],1);
>
> ??????????????? }
>
> ??????????????? ? barrier(CLK_LOCAL_MEM_FENCE);
>
> int numMembers = 2;
>
> ??????????????? if(idWithinCluster == 0)?? ????????????? {
>
> ??????????????????????????????? clusterCount[index] = atom_add(&sTemp[0],
> numMembers);//This holds the prefix offset
>
> ??????????????? }
>
> ?? delta_d[xx] = clusterCount[index];
>
> }
>
>
>
> produces bitcode file which has 3 barriers.
>
>
>
> The problem is now that the second if/barrier pair:
>
> if (point_id < num_objects) {
>
> ??? idWithinCluster = atom_add(&clusterCount
>
> ?????????????????????????????? [index],1);
>
> ??????????????? }
>
> ??????????????? ? barrier(CLK_LOCAL_MEM_FENCE);
>
>
>
>
>
> is transformed into flow control equivalent to :
>
> if (point_id >= num_objects) {
>
> ? barrier(CLK_LOCAL_MEM_FENCE);
>
> } else {
>
> ??? idWithinCluster = atom_add(&clusterCount
>
> ?????????????????????????????? [index],1);
>
> ? barrier(CLK_LOCAL_MEM_FENCE);
>
> }
>
>
>
> which violates opencl, which can cause undefined behavior on the underlying
> hardware, as each barrier is unique.
>
>
>
> So we want to disable all optimizations around barrier instructions, but not
> in other cases when no barrier instruction exists. One way to do this is to
> mark an instruction as not being copyable, but is there a method of doing
> this in LLVM?
>
>
>
> Also, this barrier does not map to llvm.barrier because llvm.barrier only
> seems to worry about memory operations and not synchronization between
> threads.
>
>
>
> Thanks for any help,
>
> Micah
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From Axel.Naumann at cern.ch  Wed Oct  7 17:19:42 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Thu, 8 Oct 2009 00:19:42 +0200
Subject: [LLVMdev] LLVM as shared libraries
Message-ID: <4ACD13FE.7080504@cern.ch>

Hi,

is there an option to build LLVM's libs (and maybe clangs, but that's
for later :-) as shared libraries? It's not --enable-shared :-) If it
doesn't exist: is there any interest to have it? It would reduce my
build time considerably...

Cheers, Axel.

From viridia at gmail.com  Wed Oct  7 17:21:20 2009
From: viridia at gmail.com (Talin)
Date: Wed, 7 Oct 2009 15:21:20 -0700
Subject: [LLVMdev] DebugFactory
In-Reply-To: <352a1fb20910070950r4fb8acc0r69682c4a20c50226@mail.gmail.com>
References: <4AB87938.6080807@gmail.com>
	<352a1fb20909220921h7577d473v90c9c61c05de61ca@mail.gmail.com>
	<352a1fb20909220921w5c61511am5712e49a3a3b6cfa@mail.gmail.com>
	<d1b71f830909221649l4e2233c1h215d88529ea8ee2c@mail.gmail.com>
	<58C4E46A-95EC-40E2-9E1F-4E9E09C8B699@apple.com>
	<d1b71f830909231427r51de6aeek53d4aa78abcd7122@mail.gmail.com>
	<352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>
	<d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>
	<352a1fb20910070950r4fb8acc0r69682c4a20c50226@mail.gmail.com>
Message-ID: <d1b71f830910071521u20f4050bh421472e98e375162@mail.gmail.com>

OK so the problem is that the compiler sees '0' and can't decide whether its
an integer or a null pointer of type Constant *. I guess the new functions
will have to have slightly different names.

On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote:

> On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote:
> > Here is a patch that does just that.
>
> This does not work. I'm getting
>
> llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function
> ?llvm::DIType
> clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType,
> llvm::DICompileUnit)?:
> /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225:
> error: call of overloaded ?CreateDerivedType(unsigned int&,
> llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int,
> int, int, int, llvm::DIType&)? is ambiguous
> llvm/include/llvm/Analysis/DebugInfo.h:530: note: candidates are:
> llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
> llvm::DIDescriptor, llvm::StringRef, llvm::DICompileUnit, unsigned
> int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType)
> llvm/include/llvm/Analysis/DebugInfo.h:540: note:
> llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
> llvm::DIDescriptor, const std::string&, llvm::DICompileUnit, unsigned
> int, llvm::Constant*, llvm::Constant*, llvm::Constant*, unsigned int,
> llvm::DIType)
>
> -
> Devang
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091007/f9eff881/attachment.html 

From ofv at wanadoo.es  Wed Oct  7 17:49:57 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 08 Oct 2009 00:49:57 +0200
Subject: [LLVMdev] LLVM as shared libraries
References: <4ACD13FE.7080504@cern.ch>
Message-ID: <87ab02om3u.fsf@telefonica.net>

Axel Naumann <Axel.Naumann at cern.ch> writes:

> is there an option to build LLVM's libs (and maybe clangs, but that's
> for later :-) as shared libraries? It's not --enable-shared :-) If it
> doesn't exist: is there any interest to have it? It would reduce my
> build time considerably...

With cmake it is BUILD_SHARED_LIBS

http://www.llvm.org/docs/CMake.html

The doc says it is not recommended because it increases process startup
time, which is very noticeable if you run your compiler lots of times
(i.e. a test suite).

-- 
?scar


From Axel.Naumann at cern.ch  Wed Oct  7 17:55:49 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Thu, 8 Oct 2009 00:55:49 +0200
Subject: [LLVMdev] LLVM as shared libraries
In-Reply-To: <87ab02om3u.fsf@telefonica.net>
References: <4ACD13FE.7080504@cern.ch> <87ab02om3u.fsf@telefonica.net>
Message-ID: <4ACD1C75.7030905@cern.ch>

Hi ?scar,

On 2009-10-08 00:49, ?scar Fuentes wrote:
> Axel Naumann <Axel.Naumann at cern.ch> writes:
>> is there an option to build LLVM's libs (and maybe clangs, but that's
>> for later :-) as shared libraries? 
>
> With cmake it is BUILD_SHARED_LIBS
> 
> http://www.llvm.org/docs/CMake.html

Great! So I must use CMake instead of configure / make to get shared libs?

> The doc says it is not recommended because it increases process startup
> time, which is very noticeable if you run your compiler lots of times
> (i.e. a test suite).

I'm not, I'm *building* my compiler tons of times ;-)

Thanks for your quick reply!

Cheers, Axel.

From dag at cray.com  Wed Oct  7 18:05:47 2009
From: dag at cray.com (David Greene)
Date: Wed, 7 Oct 2009 18:05:47 -0500
Subject: [LLVMdev] Eliminating Unused Globals
Message-ID: <200910071805.47791.dag@cray.com>

Is there a pass or piece of code somewhere in LLVM that knows how to delete 
GlobalVariables that are never used?  And iterate to then delete
GlobalVariables that only were used (in their initializers) by GlobalVariables
previously deleted?

                             -Dave

From jyasskin at google.com  Wed Oct  7 18:09:34 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Wed, 7 Oct 2009 16:09:34 -0700
Subject: [LLVMdev] Eliminating Unused Globals
In-Reply-To: <200910071805.47791.dag@cray.com>
References: <200910071805.47791.dag@cray.com>
Message-ID: <bb55930e0910071609xa122741t2e33e657d7dd5192@mail.gmail.com>

On Wed, Oct 7, 2009 at 4:05 PM, David Greene <dag at cray.com> wrote:
> Is there a pass or piece of code somewhere in LLVM that knows how to delete
> GlobalVariables that are never used? ?And iterate to then delete
> GlobalVariables that only were used (in their initializers) by GlobalVariables
> previously deleted?

http://llvm.org/docs/Passes.html#globaldce


From idadesub at users.sourceforge.net  Wed Oct  7 18:21:38 2009
From: idadesub at users.sourceforge.net (Erick Tryzelaar)
Date: Wed, 7 Oct 2009 16:21:38 -0700
Subject: [LLVMdev] InitializeNativeTarget
In-Reply-To: <4ACCDFA8.3000409@t-online.de>
References: <400d33ea0910070731o486e787ahb3fd7636b7ae8c9a@mail.gmail.com> 
	<4ACCDFA8.3000409@t-online.de>
Message-ID: <1ef034530910071621ke4aab1bu1ecf6509f71c831d@mail.gmail.com>

On Wed, Oct 7, 2009 at 11:36 AM, Albert Graef <Dr.Graef at t-online.de> wrote:
> Kenneth Uildriks wrote:
>
> Yes, so you'll need to add a little C++ module to your wrapper that does
> the necessary initializations and is callable from your target language.

That's odd, we don't need to do that for ocaml. Have you tried having
a function like this defined in your binding?

/* Force the LLVM interpreter and JIT to be linked in. */
void llvm_initialize(void) {
  LLVMLinkInInterpreter();
  LLVMLinkInJIT();
}

You don't have to call it, it's just there to make sure the execution
engine is actually linked with the binding library.

From kennethuil at gmail.com  Wed Oct  7 18:28:50 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Wed, 7 Oct 2009 18:28:50 -0500
Subject: [LLVMdev] InitializeNativeTarget
In-Reply-To: <1ef034530910071621ke4aab1bu1ecf6509f71c831d@mail.gmail.com>
References: <400d33ea0910070731o486e787ahb3fd7636b7ae8c9a@mail.gmail.com>
	<4ACCDFA8.3000409@t-online.de>
	<1ef034530910071621ke4aab1bu1ecf6509f71c831d@mail.gmail.com>
Message-ID: <400d33ea0910071628m3ec56b88t8d4c5e315258ae8e@mail.gmail.com>

On Wed, Oct 7, 2009 at 6:21 PM, Erick Tryzelaar
<idadesub at users.sourceforge.net> wrote:
> On Wed, Oct 7, 2009 at 11:36 AM, Albert Graef <Dr.Graef at t-online.de> wrote:
>> Kenneth Uildriks wrote:
>>
>> Yes, so you'll need to add a little C++ module to your wrapper that does
>> the necessary initializations and is callable from your target language.
>
> That's odd, we don't need to do that for ocaml. Have you tried having
> a function like this defined in your binding?
>
> /* Force the LLVM interpreter and JIT to be linked in. */
> void llvm_initialize(void) {
> ?LLVMLinkInInterpreter();
> ?LLVMLinkInJIT();
> }
>
> You don't have to call it, it's just there to make sure the execution
> engine is actually linked with the binding library.
>

But that doesn't cause the native target to be registered with the
native target registry, does it?.  Are you running against LLVM trunk?


From ofv at wanadoo.es  Wed Oct  7 18:34:32 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Thu, 08 Oct 2009 01:34:32 +0200
Subject: [LLVMdev] LLVM as shared libraries
References: <4ACD13FE.7080504@cern.ch> <87ab02om3u.fsf@telefonica.net>
	<4ACD1C75.7030905@cern.ch>
Message-ID: <8763aqok1j.fsf@telefonica.net>

Axel Naumann <Axel.Naumann at cern.ch> writes:

>> With cmake it is BUILD_SHARED_LIBS
>> 
>> http://www.llvm.org/docs/CMake.html
>
> Great! So I must use CMake instead of configure / make to get shared libs?

I don't know about configure/make. Cmake should work.

>> The doc says it is not recommended because it increases process startup
>> time, which is very noticeable if you run your compiler lots of times
>> (i.e. a test suite).
>
> I'm not, I'm *building* my compiler tons of times ;-)

It takes 8 seconds to statically link a debug-mode JITter with all
optimization passes and bitwriter on a Linux 64bits 2.4 GHz Intel
Q6600. Generates a 114 MB file. If yours requires much more time, check
that you are using a recent version of binutils.

A release mode build links much faster.

> Thanks for your quick reply!

You're welcome.

-- 
?scar


From eli.friedman at gmail.com  Wed Oct  7 19:49:39 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Wed, 7 Oct 2009 17:49:39 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
Message-ID: <f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>

On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> Is there a current way to specify that an instruction or function call
> cannot be duplicated and thus any optimizations that might want to duplicate
> this instruction would fail?

No.  Anything can be duplicated.  That could change, but you would
need to make a strong case for why other solutions won't work.

> which violates opencl, which can cause undefined behavior on the underlying
> hardware, as each barrier is unique.

If you need to maintain uniqueness, there are other ways to do that
without preventing the global from being duplicated.  For example, you
could associate each barrier with a unique global by making the
intrinsic take it as a parameter.

-Eli

From clattner at apple.com  Thu Oct  8 02:09:56 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 8 Oct 2009 00:09:56 -0700
Subject: [LLVMdev] [2.6] attention llvm users
Message-ID: <0EDC6418-AAA9-4CE3-B7A9-04C4051F0030@apple.com>

Hi All,

I'm preparing the 2.6 release notes, and need help from people that  
would like their projects to be listed in the "External Projects Using  
LLVM 2.6" section.  Please either directly commit (and remove  
"UPDATE") or email me a blurb for the release notes for your project.

Unless I hear from the projects, Pure, LDC, Roadsend PHP will be  
removed.  Send me an update and you stay :).  If anyone else wants to  
be added, please commit a blurb or email it to me.

The current release notes are here:
http://llvm.org/docs/ReleaseNotes-2.6.html

It is still a disaster that I'm gradually working into shape.

Thanks!

-Chris


From idadesub at users.sourceforge.net  Thu Oct  8 02:39:18 2009
From: idadesub at users.sourceforge.net (Erick Tryzelaar)
Date: Thu, 8 Oct 2009 00:39:18 -0700
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com> 
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
Message-ID: <1ef034530910080039s30ee5d18sb2847b94001804b9@mail.gmail.com>

On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>
> LLVMGetAttribute had a bug in it. ?Here's the revised version of the patch

Hi Kenneth!

I wouldn't say that I'm the best reviewer, but I've been doing some
work with the c bindings recently so hopefully I have some idea of
what I'm talking about :) Comments are inlined:


+/** See the llvm::Use class. */
+typedef struct LLVMOpaqueUse *LLVMUseRef;
+
...
+void LLVMReplaceAllUsesWith(LLVMValueRef OldVal, LLVMValueRef NewVal);
...
+/* Operations on Uses */
+LLVMUseRef LLVMGetFirstUse(LLVMValueRef Val);
+LLVMUseRef LLVMGetNextUse(LLVMUseRef U);
+LLVMValueRef LLVMGetUser(LLVMUseRef U);
+LLVMValueRef LLVMGetUsedValue(LLVMUseRef U);


These seem okay to me, but I don't have too much experience with using
the Use classes. The impression I've gotten from the other developers
is that the C bindings is really designed to just get data into llvm,
and any complex manipulations should really be done in C++ passes.
What's your use case for exposing these more complex manipulations?


+/* Operations on Users */
+LLVMValueRef LLVMGetOperand(LLVMValueRef Val, unsigned Index);


So how are you using this, since you aren't exposing any of the other
operand functionality?


+unsigned long long LLVMConstIntGetZExtValue(LLVMValueRef ConstantVal);
+long long LLVMConstIntGetSExtValue(LLVMValueRef ConstantVal);


I'm not sure about these functions. There really isn't any other way
to get to the value of any other constant, so why do you need this?


 /* Operations on composite constants */
@@ -464,6 +479,7 @@
 LLVMValueRef LLVMConstVector(LLVMValueRef *ScalarConstantVals, unsigned Size);

 /* Constant expressions */
+unsigned LLVMGetConstOpcode(LLVMValueRef ConstantVal);


This seems okay with me, but there really should be an LLVMInstruction
enum defined instead of a raw unsigned value. Could you also add a
LLVMConstExpr that wraps ConstantExpr::get?


+int LLVMHasInitializer(LLVMValueRef GlobalVar);


Seems fine to me. I can commit this now.


+LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn);
+LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg);


I've never really done much with attributes. What are you using this for?


From kennethuil at gmail.com  Thu Oct  8 07:20:57 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Thu, 8 Oct 2009 07:20:57 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <1ef034530910080039s30ee5d18sb2847b94001804b9@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<1ef034530910080039s30ee5d18sb2847b94001804b9@mail.gmail.com>
Message-ID: <400d33ea0910080520h4844ecc7o531bcd6c01a5a729@mail.gmail.com>

On Thu, Oct 8, 2009 at 2:39 AM, Erick Tryzelaar
<idadesub at users.sourceforge.net> wrote:
> On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>>
>> LLVMGetAttribute had a bug in it. ?Here's the revised version of the patch
>
> Hi Kenneth!
>
> I wouldn't say that I'm the best reviewer, but I've been doing some
> work with the c bindings recently so hopefully I have some idea of
> what I'm talking about :) Comments are inlined:

Thanks.  Let me start by talking a bit about my project.

I'm working on a compiler/language that supports run-time code
generation and compile-time code execution.  Besides the obvious
benefits of easier JITting, I also get the benefits of C++ templates
and metaprogramming without all of the headaches.

To make this work, the compiler actually compiles functions down into
function generators, outputting calls to the LLVM C-bindings that
generate a "regular" function.  The programmer can then either leave
them in that form for run-time JITting, or have the compiler JIT and
execute those function generators in order to get "regular" functions.
 Either or both can be exposed as public functions and left in place
by the optimizer.  The function generator gets its own set of
parameters, and multiple functions with variations can be generated at
compile time or runtime.

He can also put compile-time expressions inside the body of functions,
so that when the function generator runs, the compile-time expressions
are evaluated and used for function generation.  Those compile-time
expressions can use global variables and/or the function generator
parameters..

Anyway, this scheme means that extensive LLVM capability needs to be
available to generated code, since it's the generated code that
creates all of the "regular" functions.  Generated code has a much
easier time calling the C bindings than the C++ API.

>
>
> +/** See the llvm::Use class. */
> +typedef struct LLVMOpaqueUse *LLVMUseRef;
> +
> ...
> +void LLVMReplaceAllUsesWith(LLVMValueRef OldVal, LLVMValueRef NewVal);
> ...
> +/* Operations on Uses */
> +LLVMUseRef LLVMGetFirstUse(LLVMValueRef Val);
> +LLVMUseRef LLVMGetNextUse(LLVMUseRef U);
> +LLVMValueRef LLVMGetUser(LLVMUseRef U);
> +LLVMValueRef LLVMGetUsedValue(LLVMUseRef U);
>
>
> These seem okay to me, but I don't have too much experience with using
> the Use classes. The impression I've gotten from the other developers
> is that the C bindings is really designed to just get data into llvm,
> and any complex manipulations should really be done in C++ passes.
> What's your use case for exposing these more complex manipulations?

I'm using it to support renaming functions and still allowing
generated code to look up those functions by name; basically searching
for all global strings containing the function name, and replacing all
uses of them with uses of the new function name.

I would like to do away with that, though, but I haven't quite managed
to get rid of all cases where LLVMGetNamedFunction is called by
generated code.

Also, I've gotten the impression from other developers that the
C-bindings are considered incomplete and that there is a general
desire to expose more functionality, and eventually all LLVM
functionality, through them.

>
>
> +/* Operations on Users */
> +LLVMValueRef LLVMGetOperand(LLVMValueRef Val, unsigned Index);
>
>
> So how are you using this, since you aren't exposing any of the other
> operand functionality?

This supports the "address-of" operator.  Any Value that is a LoadInst
can have its address taken.  I need the pointer operand of the
LoadInst to get the address Value.

I figured GetOperand was a good starting point, and could support most
of the operand use cases out there.

>
>
> +unsigned long long LLVMConstIntGetZExtValue(LLVMValueRef ConstantVal);
> +long long LLVMConstIntGetSExtValue(LLVMValueRef ConstantVal);
>
>
> I'm not sure about these functions. There really isn't any other way
> to get to the value of any other constant, so why do you need this?

When I've parsed an int literal and put it on my evaluation stack as a
Value, there's a case where I need to get it back as an int.
Specifically, the LLVMBuildExtractValue function requires an int, not
a Constant, to represent the member.  I believe that GEP does as well
when applied to a struct.

>
>
> ?/* Operations on composite constants */
> @@ -464,6 +479,7 @@
> ?LLVMValueRef LLVMConstVector(LLVMValueRef *ScalarConstantVals, unsigned Size);
>
> ?/* Constant expressions */
> +unsigned LLVMGetConstOpcode(LLVMValueRef ConstantVal);
>
>
> This seems okay with me, but there really should be an LLVMInstruction
> enum defined instead of a raw unsigned value. Could you also add a
> LLVMConstExpr that wraps ConstantExpr::get?

That shouldn't be a problem.

>
>
> +int LLVMHasInitializer(LLVMValueRef GlobalVar);
>
>
> Seems fine to me. I can commit this now.
>
>
> +LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn);
> +LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg);
>
>
> I've never really done much with attributes. What are you using this for?
>

In order to do away with include files, I'm supporting importing
modules in bitcode form.  To call a function from an imported module,
I need to put an external into the compiled module, and it really
ought to have the same function and argument attributes as the
original.  And I want to be able to do that while JITting at runtime
as well.


From kennethuil at gmail.com  Thu Oct  8 11:19:32 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Thu, 8 Oct 2009 11:19:32 -0500
Subject: [LLVMdev] Is ExecutionEngine always meant to be a singleton?
Message-ID: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com>

Right now, on X86, creating multiple ExecutionEngines in the same
process causes an assertion.

If it's supposed to always be a singleton, should there be a way to
get the process's ExecutionEngine instance?

This would, among other things, allow "lli" to execute bitcode that
itself uses the ExecutionEngine.

From Micah.Villmow at amd.com  Thu Oct  8 12:49:37 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 8 Oct 2009 10:49:37 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>



> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: Wednesday, October 07, 2009 5:50 PM
> To: Villmow, Micah
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
> 
> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
<Micah.Villmow at amd.com>
> wrote:
> > Is there a current way to specify that an instruction or function
> call
> > cannot be duplicated and thus any optimizations that might want to
> duplicate
> > this instruction would fail?
> 
> No.  Anything can be duplicated.  That could change, but you would
> need to make a strong case for why other solutions won't work.
[Villmow, Micah] Well the problem is that the function in question
cannot get duplicated because it has side-effects that duplicating
causes undefined behavior on vector hardware. Also, moving the
instruction inside of flow control when it is originally outside of flow
control produces undefined behavior. There currently is no way to
specify this in LLVM that I know of. We've tried lowering it to an
intrinsic and setting MayWriteMem and this does not solve the problem.
After looking at the llvm IR, there is no equivalent method of
representing an instruction that is an execution barrier(not a memory
barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any idea's,
we would be willing to give them a try.


On the unique barrier issue, even if the barrier is given a unique
global identifier, it is the function duplication that causes the
problem. A unique global identifier lets us identify that invalid
optimizations have occurred, but it does not guarantee correctness since
the barrier function is unique per function call. So any sort of
duplication is invalid.
Micah




From mav at cuma.i-did-not-set--mail-host-address--so-tickle-me  Thu Oct  8 12:50:16 2009
From: mav at cuma.i-did-not-set--mail-host-address--so-tickle-me (Maurizio Vitale)
Date: Thu, 08 Oct 2009 13:50:16 -0400
Subject: [LLVMdev] question on code in PointerIntPair.h
Message-ID: <87bpkhpyg7.fsf@cuma.i-did-not-set--mail-host-address--so-tickle-me>

around line 45 a bitmask is computed as:

    PointerBitMask =
      ~(uintptr_t)(((intptr_t)1 << PtrTraits::NumLowBitsAvailable)-1),

my question is why is the shift performed on intptr_t? Wouldn't the
following be ok?
          
    PointerBitMask =
      ~(((uintptr_t)1 << PtrTraits::NumLowBitsAvailable)-1),

Thanks in advance,

       Maurizio


From jyasskin at google.com  Thu Oct  8 13:08:32 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Thu, 8 Oct 2009 11:08:32 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
Message-ID: <bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>

On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>
>
>> -----Original Message-----
>> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>> Sent: Wednesday, October 07, 2009 5:50 PM
>> To: Villmow, Micah
>> Cc: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>
>> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
> <Micah.Villmow at amd.com>
>> wrote:
>> > Is there a current way to specify that an instruction or function
>> call
>> > cannot be duplicated and thus any optimizations that might want to
>> duplicate
>> > this instruction would fail?
>>
>> No. ?Anything can be duplicated. ?That could change, but you would
>> need to make a strong case for why other solutions won't work.
> [Villmow, Micah] Well the problem is that the function in question
> cannot get duplicated because it has side-effects that duplicating
> causes undefined behavior on vector hardware. Also, moving the
> instruction inside of flow control when it is originally outside of flow
> control produces undefined behavior. There currently is no way to
> specify this in LLVM that I know of. We've tried lowering it to an
> intrinsic and setting MayWriteMem and this does not solve the problem.
> After looking at the llvm IR, there is no equivalent method of
> representing an instruction that is an execution barrier(not a memory
> barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any idea's,
> we would be willing to give them a try.

Is the effect similar to pthread_barrier_wait(barrier_for($pc))
[http://linux.die.net/man/3/pthread_barrier_wait]  where the
implementation automatically generates the barrier_for() function and
automatically calculates the number of threads to wait for?

If the barrier lowers to any sort of function call, it sounds like
you're currently looking up the PC of the caller and finding the
barrier that way. Instead, could specify the barrier as an explicit
argument to the function when your frontend generates the call
instruction, which would free you from worrying about whether the call
winds up in multiple places in the optimized IR.

If the barrier lowers to a magic instruction on your chip, and that
instruction doesn't take an ID of any sort besides its address, you
could generate a one-instruction function for each barrier() in the
source language and allow calls to that function to be duplicated.
There may be optimizations that merge "identical" functions, but
they'll be easier to turn off than optimizations that assume they can
rearrange control flow.

If your chip doesn't support function calls, that might constitute the
strong case Eli's asking for.

> On the unique barrier issue, even if the barrier is given a unique
> global identifier, it is the function duplication that causes the
> problem. A unique global identifier lets us identify that invalid
> optimizations have occurred, but it does not guarantee correctness since
> the barrier function is unique per function call. So any sort of
> duplication is invalid.
> Micah


From Micah.Villmow at amd.com  Thu Oct  8 13:28:26 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Thu, 8 Oct 2009 11:28:26 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>



> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin at google.com]
> Sent: Thursday, October 08, 2009 11:09 AM
> To: Villmow, Micah
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
> 
> On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> >> Sent: Wednesday, October 07, 2009 5:50 PM
> >> To: Villmow, Micah
> >> Cc: LLVM Developers Mailing List
> >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
> >>
> >> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
> > <Micah.Villmow at amd.com>
> >> wrote:
> >> > Is there a current way to specify that an instruction or function
> >> call
> >> > cannot be duplicated and thus any optimizations that might want to
> >> duplicate
> >> > this instruction would fail?
> >>
> >> No. ?Anything can be duplicated. ?That could change, but you would
> >> need to make a strong case for why other solutions won't work.
> > [Villmow, Micah] Well the problem is that the function in question
> > cannot get duplicated because it has side-effects that duplicating
> > causes undefined behavior on vector hardware. Also, moving the
> > instruction inside of flow control when it is originally outside of
> flow
> > control produces undefined behavior. There currently is no way to
> > specify this in LLVM that I know of. We've tried lowering it to an
> > intrinsic and setting MayWriteMem and this does not solve the
> problem.
> > After looking at the llvm IR, there is no equivalent method of
> > representing an instruction that is an execution barrier(not a memory
> > barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any
> idea's,
> > we would be willing to give them a try.
> 
> Is the effect similar to pthread_barrier_wait(barrier_for($pc))
> [http://linux.die.net/man/3/pthread_barrier_wait]  where the
> implementation automatically generates the barrier_for() function and
> automatically calculates the number of threads to wait for?
> 
> If the barrier lowers to any sort of function call, it sounds like
> you're currently looking up the PC of the caller and finding the
> barrier that way. Instead, could specify the barrier as an explicit
> argument to the function when your frontend generates the call
> instruction, which would free you from worrying about whether the call
> winds up in multiple places in the optimized IR.
> 
> If the barrier lowers to a magic instruction on your chip, and that
> instruction doesn't take an ID of any sort besides its address, you
> could generate a one-instruction function for each barrier() in the
> source language and allow calls to that function to be duplicated.
> There may be optimizations that merge "identical" functions, but
> they'll be easier to turn off than optimizations that assume they can
> rearrange control flow.
> 
> If your chip doesn't support function calls, that might constitute the
> strong case Eli's asking for.
[Villmow, Micah] Jeffrey thanks for the information on pthread. The barrier on our hardware is a single instruction, not a function call, with no arguments and everything is handled implicitly, including keeping track of the number of hardware threads that need to hit the barrier. If one of those hardware threads does not hit the barrier, then it causes undefined behavior. Hence why we need to guarantee that this instruction is not optimized around, moved or duplicated as the algorithm writer must place it following strict guidelines for it to work correctly.

So, my strong case for some sort of workaround is this:

Valid original code is:
 flag = false
 if (cond) 
    { flag = bar();
 }
 foo()
 if (flag) {bar}


transformes to 

if (cond) {
    flag = bar()
    foo()
    if (flag) 
        bar()
} else {
   foo()
}

Assumptions:
- foo() is the barrier 
- each hardware thread is a 64wide vector 
- two hardware threads are executing
- Each vector element gets a unique id between 0 and 127
- The condition is true if id > 32
- Predication is used on control flow
What happens in the original code:
The first half of the  first hardware thread predicates computation on the first condition, second half executes bar and all threads in the second wavefront execute bar. Both hardware threads hit the barrier and wait for the other hardware thread to reach that point, then continue execution.

What happens in the optimized code:
first half of the first hardware thread predicates computation on the first condition, the second half executes bar and waits at the barrier. The second hardware thread executes bar and hits the barrier, forcing continuation of execution. Both the first and second hardware thread executes the rest of the if block. Once the block ends, the predication masks are flipped and the second half of the first hardware thread hits the barrier and blocks waiting for the second hardware thread. The second hardware thread skips execution of the else block thus not hitting the barrier, causing the first hardware thread to never return from barrier.

We have already detected two optimization passes(Loopunswitch and simplifycfg) that perform these type of transforms, and we are sure there might be more. We want to be able to enable these transforms for normal code, but have them respect the barrier instruction.


Thanks again,
Micah
> 
> > On the unique barrier issue, even if the barrier is given a unique
> > global identifier, it is the function duplication that causes the
> > problem. A unique global identifier lets us identify that invalid
> > optimizations have occurred, but it does not guarantee correctness
> since
> > the barrier function is unique per function call. So any sort of
> > duplication is invalid.
> > Micah




From devang.patel at gmail.com  Thu Oct  8 14:59:48 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Thu, 8 Oct 2009 12:59:48 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
Message-ID: <352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>

On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>
>
>> -----Original Message-----
>> From: Jeffrey Yasskin [mailto:jyasskin at google.com]
>> Sent: Thursday, October 08, 2009 11:09 AM
>> To: Villmow, Micah
>> Cc: LLVM Developers Mailing List
>> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>
>> On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com>
>> wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>> >> Sent: Wednesday, October 07, 2009 5:50 PM
>> >> To: Villmow, Micah
>> >> Cc: LLVM Developers Mailing List
>> >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>> >>
>> >> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
>> > <Micah.Villmow at amd.com>
>> >> wrote:
>> >> > Is there a current way to specify that an instruction or function
>> >> call
>> >> > cannot be duplicated and thus any optimizations that might want to
>> >> duplicate
>> >> > this instruction would fail?
>> >>
>> >> No. ?Anything can be duplicated. ?That could change, but you would
>> >> need to make a strong case for why other solutions won't work.
>> > [Villmow, Micah] Well the problem is that the function in question
>> > cannot get duplicated because it has side-effects that duplicating
>> > causes undefined behavior on vector hardware. Also, moving the
>> > instruction inside of flow control when it is originally outside of
>> flow
>> > control produces undefined behavior. There currently is no way to
>> > specify this in LLVM that I know of. We've tried lowering it to an
>> > intrinsic and setting MayWriteMem and this does not solve the
>> problem.
>> > After looking at the llvm IR, there is no equivalent method of
>> > representing an instruction that is an execution barrier(not a memory
>> > barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any
>> idea's,
>> > we would be willing to give them a try.
>>
>> Is the effect similar to pthread_barrier_wait(barrier_for($pc))
>> [http://linux.die.net/man/3/pthread_barrier_wait] ?where the
>> implementation automatically generates the barrier_for() function and
>> automatically calculates the number of threads to wait for?
>>
>> If the barrier lowers to any sort of function call, it sounds like
>> you're currently looking up the PC of the caller and finding the
>> barrier that way. Instead, could specify the barrier as an explicit
>> argument to the function when your frontend generates the call
>> instruction, which would free you from worrying about whether the call
>> winds up in multiple places in the optimized IR.
>>
>> If the barrier lowers to a magic instruction on your chip, and that
>> instruction doesn't take an ID of any sort besides its address, you
>> could generate a one-instruction function for each barrier() in the
>> source language and allow calls to that function to be duplicated.
>> There may be optimizations that merge "identical" functions, but
>> they'll be easier to turn off than optimizations that assume they can
>> rearrange control flow.
>>
>> If your chip doesn't support function calls, that might constitute the
>> strong case Eli's asking for.
> [Villmow, Micah] Jeffrey thanks for the information on pthread. The barrier on our hardware is a single instruction, not a function call, with no arguments and everything is handled implicitly, including keeping track of the number of hardware threads that need to hit the barrier. If one of those hardware threads does not hit the barrier, then it causes undefined behavior. Hence why we need to guarantee that this instruction is not optimized around, moved or duplicated as the algorithm writer must place it following strict guidelines for it to work correctly.
>
> So, my strong case for some sort of workaround is this:
>
> Valid original code is:
> ?flag = false
> ?if (cond)
> ? ?{ flag = bar();
> ?}
> ?foo()
> ?if (flag) {bar}
>
>
> transformes to
>
> if (cond) {
> ? ?flag = bar()
> ? ?foo()
> ? ?if (flag)
> ? ? ? ?bar()
> } else {
> ? foo()
> }
>
> Assumptions:
> - foo() is the barrier
> - each hardware thread is a 64wide vector
> - two hardware threads are executing
> - Each vector element gets a unique id between 0 and 127
> - The condition is true if id > 32
> - Predication is used on control flow
> What happens in the original code:
> The first half of the ?first hardware thread predicates computation on the first condition, second half executes bar and all threads in the second wavefront execute bar. Both hardware threads hit the barrier and wait for the other hardware thread to reach that point, then continue execution.
>
> What happens in the optimized code:
> first half of the first hardware thread predicates computation on the first condition, the second half executes bar and waits at the barrier. The second hardware thread executes bar and hits the barrier, forcing continuation of execution. Both the first and second hardware thread executes the rest of the if block. Once the block ends, the predication masks are flipped and the second half of the first hardware thread hits the barrier and blocks waiting for the second hardware thread. The second hardware thread skips execution of the else block thus not hitting the barrier, causing the first hardware thread to never return from barrier.
>
> We have already detected two optimization passes(Loopunswitch and simplifycfg) that perform these type of transforms, and we are sure there might be more. We want to be able to enable these transforms for normal code, but have them respect the barrier instruction.

... and even if a new barrier intrinsic that does not allow cloning
(not sure how, but anyway...) is introduced, you'll have to modify all
these optimization passes to take a note of this special barrier. New
barrier won't be respected automatically.

Have you thought about dividing code in separate functions and make
sure the inliner does not inline them ?

fn1() /* do not inline */
your barrier()
fn2() /* do not inline */


-
Devang


From rnk at mit.edu  Thu Oct  8 16:11:31 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Thu, 8 Oct 2009 17:11:31 -0400
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com> 
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com> 
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com> 
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com> 
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com> 
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
Message-ID: <9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>

On Thu, Oct 8, 2009 at 3:59 PM, Devang Patel <devang.patel at gmail.com> wrote:
> On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jeffrey Yasskin [mailto:jyasskin at google.com]
>>> Sent: Thursday, October 08, 2009 11:09 AM
>>> To: Villmow, Micah
>>> Cc: LLVM Developers Mailing List
>>> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>>
>>> On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com>
>>> wrote:
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>>> >> Sent: Wednesday, October 07, 2009 5:50 PM
>>> >> To: Villmow, Micah
>>> >> Cc: LLVM Developers Mailing List
>>> >> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>> >>
>>> >> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
>>> > <Micah.Villmow at amd.com>
>>> >> wrote:
>>> >> > Is there a current way to specify that an instruction or function
>>> >> call
>>> >> > cannot be duplicated and thus any optimizations that might want to
>>> >> duplicate
>>> >> > this instruction would fail?
>>> >>
>>> >> No. ?Anything can be duplicated. ?That could change, but you would
>>> >> need to make a strong case for why other solutions won't work.
>>> > [Villmow, Micah] Well the problem is that the function in question
>>> > cannot get duplicated because it has side-effects that duplicating
>>> > causes undefined behavior on vector hardware. Also, moving the
>>> > instruction inside of flow control when it is originally outside of
>>> flow
>>> > control produces undefined behavior. There currently is no way to
>>> > specify this in LLVM that I know of. We've tried lowering it to an
>>> > intrinsic and setting MayWriteMem and this does not solve the
>>> problem.
>>> > After looking at the llvm IR, there is no equivalent method of
>>> > representing an instruction that is an execution barrier(not a memory
>>> > barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any
>>> idea's,
>>> > we would be willing to give them a try.
>>>
>>> Is the effect similar to pthread_barrier_wait(barrier_for($pc))
>>> [http://linux.die.net/man/3/pthread_barrier_wait] ?where the
>>> implementation automatically generates the barrier_for() function and
>>> automatically calculates the number of threads to wait for?
>>>
>>> If the barrier lowers to any sort of function call, it sounds like
>>> you're currently looking up the PC of the caller and finding the
>>> barrier that way. Instead, could specify the barrier as an explicit
>>> argument to the function when your frontend generates the call
>>> instruction, which would free you from worrying about whether the call
>>> winds up in multiple places in the optimized IR.
>>>
>>> If the barrier lowers to a magic instruction on your chip, and that
>>> instruction doesn't take an ID of any sort besides its address, you
>>> could generate a one-instruction function for each barrier() in the
>>> source language and allow calls to that function to be duplicated.
>>> There may be optimizations that merge "identical" functions, but
>>> they'll be easier to turn off than optimizations that assume they can
>>> rearrange control flow.
>>>
>>> If your chip doesn't support function calls, that might constitute the
>>> strong case Eli's asking for.
>> [Villmow, Micah] Jeffrey thanks for the information on pthread. The barrier on our hardware is a single instruction, not a function call, with no arguments and everything is handled implicitly, including keeping track of the number of hardware threads that need to hit the barrier. If one of those hardware threads does not hit the barrier, then it causes undefined behavior. Hence why we need to guarantee that this instruction is not optimized around, moved or duplicated as the algorithm writer must place it following strict guidelines for it to work correctly.
>>
>> So, my strong case for some sort of workaround is this:
>>
>> Valid original code is:
>> ?flag = false
>> ?if (cond)
>> ? ?{ flag = bar();
>> ?}
>> ?foo()
>> ?if (flag) {bar}
>>
>>
>> transformes to
>>
>> if (cond) {
>> ? ?flag = bar()
>> ? ?foo()
>> ? ?if (flag)
>> ? ? ? ?bar()
>> } else {
>> ? foo()
>> }
>>
>> Assumptions:
>> - foo() is the barrier
>> - each hardware thread is a 64wide vector
>> - two hardware threads are executing
>> - Each vector element gets a unique id between 0 and 127
>> - The condition is true if id > 32
>> - Predication is used on control flow
>> What happens in the original code:
>> The first half of the ?first hardware thread predicates computation on the first condition, second half executes bar and all threads in the second wavefront execute bar. Both hardware threads hit the barrier and wait for the other hardware thread to reach that point, then continue execution.
>>
>> What happens in the optimized code:
>> first half of the first hardware thread predicates computation on the first condition, the second half executes bar and waits at the barrier. The second hardware thread executes bar and hits the barrier, forcing continuation of execution. Both the first and second hardware thread executes the rest of the if block. Once the block ends, the predication masks are flipped and the second half of the first hardware thread hits the barrier and blocks waiting for the second hardware thread. The second hardware thread skips execution of the else block thus not hitting the barrier, causing the first hardware thread to never return from barrier.
>>
>> We have already detected two optimization passes(Loopunswitch and simplifycfg) that perform these type of transforms, and we are sure there might be more. We want to be able to enable these transforms for normal code, but have them respect the barrier instruction.
>
> ... and even if a new barrier intrinsic that does not allow cloning
> (not sure how, but anyway...) is introduced, you'll have to modify all
> these optimization passes to take a note of this special barrier. New
> barrier won't be respected automatically.
>
> Have you thought about dividing code in separate functions and make
> sure the inliner does not inline them ?
>
> fn1() /* do not inline */
> your barrier()
> fn2() /* do not inline */

IMO Jeff's solution is the cleanest, simplest way to get code that
works.  Just generate a separate function for every barrier in the
program, and mark it noinline.  This way the instruction pointers will
be unique to the barrier.

Reid


From terence.p.kelly at hp.com  Thu Oct  8 17:26:18 2009
From: terence.p.kelly at hp.com (Kelly, Terence P (HP Labs Researcher))
Date: Thu, 8 Oct 2009 22:26:18 +0000
Subject: [LLVMdev] strace for whole-program bitcodes (was: RE: building
 whole-program bitcode with LLVM)
Message-ID: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>


Hi,

It would be nice if it were easier for relative
novices to build whole-program bitcodes for
large, complex applications with hairy build
systems.  Several readers of this list have
been trying various approaches for a few months
but as far as I know we haven't yet found a
good general solution.  Approaches that have
been tried include 1) placing wrappers for the
usual tools (gcc, ar, as, ld, etc.) first on
the $PATH, and having the wrappers pass the
buck to the LLVM equivalent tools after cleaning
up the arguments; and 2) using the Gold plugin.

Recently another possibility occurred to me,
and I'm wondering if anyone has tried it.
The basic idea goes like this:  A) use the
"strace" utility to trace the default build
system and log all invocations of all tools;
B) extract from the log a build recipe in the
form of tool invocations, with the default
tools replaced by LLVM equivalents.

I started thinking along these lines after
finding some genuine madness in a build system
(it used AWK to munge together existing .c files
into new ones midway through the build).  I want
a method that's guaranteed to mimic faithfully
an arbitrarily nutty default build system, and
an strace-based approach seemed like a "Gordian
knot" solution.  However I haven't tried it yet
and I'm wondering if anyone else has, or if
anyone can think of situations where it will
fail.

Thanks!

-- Terence

> -----Original Message-----
> From: Kelly, Terence P (HP Labs Researcher) 
> Sent: Friday, July 31, 2009 6:12 PM
> To: 'llvmdev at cs.uiuc.edu'
> Cc: 'Vikram S. Adve'
> Subject: building whole-program bitcode with LLVM
> 
> 
> Hi,
> 
> Professor Adve suggested that we post this question to llvm-dev.
> Thanks in advance for your advice.
> 
> My colleagues and I want to create whole-program bitcode for large
> real programs like Apache, BIND, OpenLDAP, etc.  We want the
> whole-program bitcode to include every part of the program for which
> we have source code.  For example, in the case of Apache's "httpd"
> server, we want to create a whole-program bitcode file "httpd.bc"
> containing functions that the default build system stashes in various
> application-specific auxiliary libraries (e.g., Apache's libapr and
> libaprutil).
> 
> Our motive is *not* link-time optimization; we're interested in
> analyzing and modifying the whole-program bitcode in other ways.
> Once we have created a whole-program bitcode, we want to compile it
> to native assembly, then pass it thru the native assembler & linker
> to obtain a native executable whose behavior (except for performance)
> is identical to that of an executable obtained from the default build
> system.  We do *not* want standard libraries like libc and libpthread
> to be incorporated as bitcode in the whole-program bitcode; they can
> be linked in at the final step, after we have converted the
> whole-program bitcode to native assembly and assembled & linked it.
> 
> We have been able to achieve our goal for small programs consisting
> of a handful of translation units, so we know that our goal is
> attainable in principle.  Problems start when we tackle big programs
> with complex build systems.  We want to find a generic strategy that
> works with most real world open source C/C++ programs without too
> much fuss, because we want to use it on at least a dozen different
> programs.  Ideally we want a strategy that works with unmodified
> default build systems, because eventually we hope to produce a tool
> that is easy for other developers to use.
> 
> Initially we had hoped simply to replace gcc, as, ld, etc. with their
> LLVM counterparts in the standard build systems, but we haven't been
> able to make that strategy work.  Several different approaches along
> these lines fail in various ways.  Some have recommended the Gold
> plugin, but it's not clear from the documentation that it does what
> we want, and we haven't been successful in installing it yet.
> 
> Does anyone have experience in constructing whole-program bitcodes
> that include app-specific libraries for large open-source programs?
> If you could share the right tricks, that would be very helpful.
> 
> Thanks!
> 
> -- Terence Kelly, HP Labs
> 
> ________________________________
> 
> From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu] 
> Sent: Friday, July 24, 2009 8:05 PM
> To: Kelly, Terence P (HP Labs Researcher)
> Cc: Swarup Sahoo
> Subject: Re: building complex software with LLVM
> 
> Hi Terence, 
> 
> ...
> 
> I also recommend sending any such technical
> questions about LLVM to llvmdev at cs.uiuc.edu.
> There are a large number of active (and very
> helpful) LLVM users on that list.  Replies
> go to the list so you should join the list
> to see them.
> 
> Good luck! 
> 
> --Vikram
> Associate Professor, Computer Science
> University of Illinois at Urbana-Champaign
> http://llvm.org/~vadve
> 
> 

From stuart at apple.com  Thu Oct  8 18:52:18 2009
From: stuart at apple.com (Stuart Hastings)
Date: Thu, 8 Oct 2009 16:52:18 -0700
Subject: [LLVMdev] fudging the top-level Makefile
Message-ID: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>

Currently, to get LLVM to build "Apple-style," it's necessary to copy  
two files (utils/buildit/GNUmakefile and utils/buildit/build_llvm)  
into the top-level directory.  This is generally a PITA inside of  
Apple.  (I'll spare you the gory details.  :-)

I'd like to fix this for Apple, and I want to avoid compromising  
anybody else's build system.  I've never used CMAKE, so I would be  
very grateful if a Windows/CMAKE developer would look this over.

I'm proposing to rename the top-level Makefile to "Makefile.standard",  
and add a new, trivial top-level "Makefile" that detects the Apple  
build environment.  Every Apple-style build happens in the presence of  
an environment variable named "$RC_ARCHS".  If the magic $RC_ARCHS is  
detected, the new Makefile arranges for an Apple-style build.  If the  
magic environment variable is absent, "Makefile.standard" is included,  
and everything proceeds as usual.

I've tested this by building LLVM on OS/X:
1) with a separate build directory, e.g. "cd llvm.obj ; ../llvm/ 
configure ; make"
2) building inside the LLVM source directory, e.g. "cd llvm ; ./ 
configure ; make"
3) Apple-style (too ugly and frightening to reproduce here :-)

I've also tested this by building LLVM on my home Linux system:
1) with a separate build directory, e.g. "cd llvm.obj ; ../llvm/ 
configure ; make"
2) building inside the LLVM source directory, e.g. "cd llvm ; ./ 
configure ; make"

Comments or suggestions (or better approaches) are greatly appreciated.

Here is the patch.  I was obliged to change autoconf/configure.ac; I  
have omitted the corresponding diffs from the top-level configure  
shellscript for brevity:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvmCore.diffs.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091008/949d6680/attachment.txt 
-------------- next part --------------


Note that the existing top-level Makefile will be renamed to  
"Makefile.standard".  (This doesn't show up very well in a simple SVN  
diff.)  Here is the new top-level Makefile:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 467 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091008/949d6680/attachment.obj 
-------------- next part --------------


Thank you very much in advance!

stuart

From mrs at apple.com  Thu Oct  8 19:18:08 2009
From: mrs at apple.com (Mike Stump)
Date: Thu, 8 Oct 2009 17:18:08 -0700
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
Message-ID: <A0929213-3743-4093-9337-FE441F24C893@apple.com>

On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote:
> Currently, to get LLVM to build "Apple-style," it's necessary to  
> copy two files (utils/buildit/GNUmakefile and utils/buildit/ 
> build_llvm) into the top-level directory.

Why not:

$ RC_ARCHS="x86" make
echo Apple Build.
Apple Build.
$ make
echo Standard Build
Standard Build
$ cat Makefile
ifneq ($(RC_ARCHS),)
include Makefile.apple
else
all:
	echo Standard Build
endif
mrs $ cat Makefile.apple
all:
	echo Apple Build.

It leaves Makefile mostly alone, all except for three lines at the top  
and one line at the end of it.

From foldr at codedgers.com  Thu Oct  8 19:32:45 2009
From: foldr at codedgers.com (Mikhail Glushenkov)
Date: Fri, 9 Oct 2009 00:32:45 +0000 (UTC)
Subject: [LLVMdev] Linking library files using llvmc
References: <c10888c30910070925u4f2991dfi7b9bea331786c00a@mail.gmail.com>
Message-ID: <loom.20091009T023107-529@post.gmane.org>

Hi Ravi,

Ravi Chandhran <kmrc87 <at> gmail.com> writes:

> 
> I was using llvmc along with the -opt option to perform static analyzes in
some of the commonly used programs like bzip2, gzip, grep etc. I found that when
llvmc is used to link libraries (.a or .so files) using the -l option it passes
the library files to the linker ( for me it was llvm-gcc itself) but changes the
order in which it was given to llvmc. 

Try a recent SVN version, this was fixed just yesterday:

http://article.gmane.org/gmane.comp.compilers.llvm.cvs/59485


From monping at apple.com  Thu Oct  8 19:35:21 2009
From: monping at apple.com (Mon Ping Wang)
Date: Thu, 8 Oct 2009 17:35:21 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
Message-ID: <AA61D67A-54AF-45B7-89E6-42226B895096@apple.com>

For these particular targets, the hardware may not support function  
calls.  So, at some point, the compiler will need to inline the  
function.  It would need to do something special since it can't inline  
in each call site but need to introduce a jump to the barrier and a  
jump back to the various basic block it came from which could be  
messy.  It would be nicer to avoid the transformation that copied  
these basic block.

-- Mon Ping


On Oct 8, 2009, at 2:11 PM, Reid Kleckner wrote:

> On Thu, Oct 8, 2009 at 3:59 PM, Devang Patel  
> <devang.patel at gmail.com> wrote:
>> On Thu, Oct 8, 2009 at 11:28 AM, Villmow, Micah <Micah.Villmow at amd.com 
>> > wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jeffrey Yasskin [mailto:jyasskin at google.com]
>>>> Sent: Thursday, October 08, 2009 11:09 AM
>>>> To: Villmow, Micah
>>>> Cc: LLVM Developers Mailing List
>>>> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>>>
>>>> On Thu, Oct 8, 2009 at 10:49 AM, Villmow, Micah <Micah.Villmow at amd.com 
>>>> >
>>>> wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Eli Friedman [mailto:eli.friedman at gmail.com]
>>>>>> Sent: Wednesday, October 07, 2009 5:50 PM
>>>>>> To: Villmow, Micah
>>>>>> Cc: LLVM Developers Mailing List
>>>>>> Subject: Re: [LLVMdev] Instructions that cannot be duplicated
>>>>>>
>>>>>> On Wed, Oct 7, 2009 at 11:20 AM, Villmow, Micah
>>>>> <Micah.Villmow at amd.com>
>>>>>> wrote:
>>>>>>> Is there a current way to specify that an instruction or  
>>>>>>> function
>>>>>> call
>>>>>>> cannot be duplicated and thus any optimizations that might  
>>>>>>> want to
>>>>>> duplicate
>>>>>>> this instruction would fail?
>>>>>>
>>>>>> No.  Anything can be duplicated.  That could change, but you  
>>>>>> would
>>>>>> need to make a strong case for why other solutions won't work.
>>>>> [Villmow, Micah] Well the problem is that the function in question
>>>>> cannot get duplicated because it has side-effects that duplicating
>>>>> causes undefined behavior on vector hardware. Also, moving the
>>>>> instruction inside of flow control when it is originally outside  
>>>>> of
>>>> flow
>>>>> control produces undefined behavior. There currently is no way to
>>>>> specify this in LLVM that I know of. We've tried lowering it to an
>>>>> intrinsic and setting MayWriteMem and this does not solve the
>>>> problem.
>>>>> After looking at the llvm IR, there is no equivalent method of
>>>>> representing an instruction that is an execution barrier(not a  
>>>>> memory
>>>>> barrier, which llvm.barrier.[ss|ll|ls|sl] is). If you have any
>>>> idea's,
>>>>> we would be willing to give them a try.
>>>>
>>>> Is the effect similar to pthread_barrier_wait(barrier_for($pc))
>>>> [http://linux.die.net/man/3/pthread_barrier_wait]  where the
>>>> implementation automatically generates the barrier_for() function  
>>>> and
>>>> automatically calculates the number of threads to wait for?
>>>>
>>>> If the barrier lowers to any sort of function call, it sounds like
>>>> you're currently looking up the PC of the caller and finding the
>>>> barrier that way. Instead, could specify the barrier as an explicit
>>>> argument to the function when your frontend generates the call
>>>> instruction, which would free you from worrying about whether the  
>>>> call
>>>> winds up in multiple places in the optimized IR.
>>>>
>>>> If the barrier lowers to a magic instruction on your chip, and that
>>>> instruction doesn't take an ID of any sort besides its address, you
>>>> could generate a one-instruction function for each barrier() in the
>>>> source language and allow calls to that function to be duplicated.
>>>> There may be optimizations that merge "identical" functions, but
>>>> they'll be easier to turn off than optimizations that assume they  
>>>> can
>>>> rearrange control flow.
>>>>
>>>> If your chip doesn't support function calls, that might  
>>>> constitute the
>>>> strong case Eli's asking for.
>>> [Villmow, Micah] Jeffrey thanks for the information on pthread.  
>>> The barrier on our hardware is a single instruction, not a  
>>> function call, with no arguments and everything is handled  
>>> implicitly, including keeping track of the number of hardware  
>>> threads that need to hit the barrier. If one of those hardware  
>>> threads does not hit the barrier, then it causes undefined  
>>> behavior. Hence why we need to guarantee that this instruction is  
>>> not optimized around, moved or duplicated as the algorithm writer  
>>> must place it following strict guidelines for it to work correctly.
>>>
>>> So, my strong case for some sort of workaround is this:
>>>
>>> Valid original code is:
>>>  flag = false
>>>  if (cond)
>>>    { flag = bar();
>>>  }
>>>  foo()
>>>  if (flag) {bar}
>>>
>>>
>>> transformes to
>>>
>>> if (cond) {
>>>    flag = bar()
>>>    foo()
>>>    if (flag)
>>>        bar()
>>> } else {
>>>   foo()
>>> }
>>>
>>> Assumptions:
>>> - foo() is the barrier
>>> - each hardware thread is a 64wide vector
>>> - two hardware threads are executing
>>> - Each vector element gets a unique id between 0 and 127
>>> - The condition is true if id > 32
>>> - Predication is used on control flow
>>> What happens in the original code:
>>> The first half of the  first hardware thread predicates  
>>> computation on the first condition, second half executes bar and  
>>> all threads in the second wavefront execute bar. Both hardware  
>>> threads hit the barrier and wait for the other hardware thread to  
>>> reach that point, then continue execution.
>>>
>>> What happens in the optimized code:
>>> first half of the first hardware thread predicates computation on  
>>> the first condition, the second half executes bar and waits at the  
>>> barrier. The second hardware thread executes bar and hits the  
>>> barrier, forcing continuation of execution. Both the first and  
>>> second hardware thread executes the rest of the if block. Once the  
>>> block ends, the predication masks are flipped and the second half  
>>> of the first hardware thread hits the barrier and blocks waiting  
>>> for the second hardware thread. The second hardware thread skips  
>>> execution of the else block thus not hitting the barrier, causing  
>>> the first hardware thread to never return from barrier.
>>>
>>> We have already detected two optimization passes(Loopunswitch and  
>>> simplifycfg) that perform these type of transforms, and we are  
>>> sure there might be more. We want to be able to enable these  
>>> transforms for normal code, but have them respect the barrier  
>>> instruction.
>>
>> ... and even if a new barrier intrinsic that does not allow cloning
>> (not sure how, but anyway...) is introduced, you'll have to modify  
>> all
>> these optimization passes to take a note of this special barrier. New
>> barrier won't be respected automatically.
>>
>> Have you thought about dividing code in separate functions and make
>> sure the inliner does not inline them ?
>>
>> fn1() /* do not inline */
>> your barrier()
>> fn2() /* do not inline */
>
> IMO Jeff's solution is the cleanest, simplest way to get code that
> works.  Just generate a separate function for every barrier in the
> program, and mark it noinline.  This way the instruction pointers will
> be unique to the barrier.
>
> Reid
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From ofv at wanadoo.es  Thu Oct  8 19:39:24 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Fri, 09 Oct 2009 02:39:24 +0200
Subject: [LLVMdev] fudging the top-level Makefile
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
Message-ID: <87zl81mmdf.fsf@telefonica.net>

Stuart Hastings <stuart at apple.com> writes:

> I'd like to fix this for Apple, and I want to avoid compromising
> anybody else's build system.  I've never used CMAKE, so I would be
> very grateful if a Windows/CMAKE developer would look this over.

As the LLVM cmake build specification completely ignores the makefiles
provided with LLVM, no problem here.

-- 
?scar


From eli.friedman at gmail.com  Thu Oct  8 22:38:59 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Thu, 8 Oct 2009 20:38:59 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
Message-ID: <f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>

On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <rnk at mit.edu> wrote:
> IMO Jeff's solution is the cleanest, simplest way to get code that
> works. ?Just generate a separate function for every barrier in the
> program, and mark it noinline. ?This way the instruction pointers will
> be unique to the barrier.

No, this gets rather nasty: to support an instruction like this, it
isn't legal to duplicate calls to functions containing a barrier
instruction.

Another proposal: add an executebarrier function attribute for
functions which directly or indirectly contain an execution barrier,
and adjust all the relevant transformation passes, like jump threading
and loop unswitching, to avoid duplicating calls to such functions.
This puts a slight burden on the frontend to mark functions
appropriately, but I don't see any other solution which doesn't affect
code which doesn't use execute barriers.

-Eli


From nicholas at mxc.ca  Fri Oct  9 01:15:39 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Thu, 08 Oct 2009 23:15:39 -0700
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
Message-ID: <4ACED50B.8000606@mxc.ca>

Sandeep Patel wrote:
> Attached is the start of a patch to make the gold plugin work on
> Darwin for use as a cross-compiler. There needs to be a build step
> somewhere in llvm-gcc that copies it into libexec/<gcc
> poop>/libLLVMgold.so, but I've been doing that manually for now.

With this patch, it seems that it produces a file named LLVMgold.so 
instead of libLLVMgold.so. Any ideas?

I'll look into it later if you're not sure why, but that's the only 
thing blocking committing it.

> It doesn't seem that simple use of -O4 results in the plugin learning
> what subtarget is desired. I presume that the llvm-gcc driver needs to
> pass -mcpu down through collect2 into ld somehow. Has anybody solved
> this already? Perhaps we should finally just put the feature string
> into the bitcode?

That's not all. -disable-fp-elim will be dropped, for example. The 
libLTO generated code assumes -mcpu=native, -march=native, frame 
pointers eliminated, etc. This should all be flag controlled but 
nobody's bothered to do it yet.

Nick

From vgrover528 at gmail.com  Fri Oct  9 01:17:58 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Thu, 8 Oct 2009 23:17:58 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
Message-ID: <35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>

Is inlining (which duplicates code) of functions containing OpenCL style
barriers legal?or e.g.

if you had some changed phase ordering where you had

if (cond) {
   S1;
}
call user_func() // user_func has a barrier buried inside it.

you do tail splitting

if (cond) {
   S1;
   call user_func()
} else {
   call user_func();
}

now you inline -- oops now you might have a problem

so do you want IPA to propagate the barrier bit to the call sites?

you could do inlining before tail splitting

sounds messy...

Vinod


On Thu, Oct 8, 2009 at 8:38 PM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <rnk at mit.edu> wrote:
> > IMO Jeff's solution is the cleanest, simplest way to get code that
> > works.  Just generate a separate function for every barrier in the
> > program, and mark it noinline.  This way the instruction pointers will
> > be unique to the barrier.
>
> No, this gets rather nasty: to support an instruction like this, it
> isn't legal to duplicate calls to functions containing a barrier
> instruction.
>
> Another proposal: add an executebarrier function attribute for
> functions which directly or indirectly contain an execution barrier,
> and adjust all the relevant transformation passes, like jump threading
> and loop unswitching, to avoid duplicating calls to such functions.
> This puts a slight burden on the frontend to mark functions
> appropriately, but I don't see any other solution which doesn't affect
> code which doesn't use execute barriers.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091008/a5a3c08a/attachment.html 

From deeppatel1987 at gmail.com  Fri Oct  9 01:23:58 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Fri, 9 Oct 2009 06:23:58 +0000
Subject: [LLVMdev] getting gold plugin to work?
In-Reply-To: <4ACED50B.8000606@mxc.ca>
References: <305d6f60910041842w30598cadyefcdea87d6b27044@mail.gmail.com>
	<4ACED50B.8000606@mxc.ca>
Message-ID: <305d6f60910082323t4ae9d591w6e00823b460ae58c@mail.gmail.com>

On Fri, Oct 9, 2009 at 6:15 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Sandeep Patel wrote:
>>
>> Attached is the start of a patch to make the gold plugin work on
>> Darwin for use as a cross-compiler. There needs to be a build step
>> somewhere in llvm-gcc that copies it into libexec/<gcc
>> poop>/libLLVMgold.so, but I've been doing that manually for now.
>
> With this patch, it seems that it produces a file named LLVMgold.so instead
> of libLLVMgold.so. Any ideas?

LOADABLE_MODULE causes that, but it is necessary to get -module passed
to libtool.

> I'll look into it later if you're not sure why, but that's the only thing
> blocking committing it.
>
>> It doesn't seem that simple use of -O4 results in the plugin learning
>> what subtarget is desired. I presume that the llvm-gcc driver needs to
>> pass -mcpu down through collect2 into ld somehow. Has anybody solved
>> this already? Perhaps we should finally just put the feature string
>> into the bitcode?
>
> That's not all. -disable-fp-elim will be dropped, for example. The libLTO
> generated code assumes -mcpu=native, -march=native, frame pointers
> eliminated, etc. This should all be flag controlled but nobody's bothered to
> do it yet.

How does this work in the Darwin linker? Or doesn't it?

deep

From monping at apple.com  Fri Oct  9 02:20:05 2009
From: monping at apple.com (Mon Ping Wang)
Date: Fri, 9 Oct 2009 00:20:05 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
Message-ID: <A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>


The requirement in OpenCL is that all threads (work-items) are  
required to hit the same barrier.  If one does what you have shown  
below, it is not legal because some threads may go through the block  
with S1 and some other threads will go the other way.  On some  
hardware, such a program will cause a hardware stall. If one is  
inlining, it is preferable to inline early assuming the rest of the  
transformations don't mess with the barrier. Eli is correct that you  
can't duplicate calls to a function containing these kind of barriers  
for the same reasons.  From the discussions so far, it would be nice  
if such a concept where you don't want to modify the control flow of a  
basic block containing such an execution barrier or a function  
containing such a barrier. This requires that all phases that does  
such optimizations would have to be made aware of it.  Such a concept  
may be also useful for other things like inline assembly where one may  
not want to duplicate a block.

   -- Mon Ping



On Oct 8, 2009, at 11:17 PM, Vinod Grover wrote:

> Is inlining (which duplicates code) of functions containing OpenCL  
> style barriers legal?
> or e.g.
>
> if you had some changed phase ordering where you had
>
> if (cond) {
>    S1;
> }
> call user_func() // user_func has a barrier buried inside it.
>
> you do tail splitting
>
> if (cond) {
>    S1;
>    call user_func()
> } else {
>    call user_func();
> }
>
> now you inline -- oops now you might have a problem
>
> so do you want IPA to propagate the barrier bit to the call sites?
>
> you could do inlining before tail splitting
>
> sounds messy...
>
> Vinod
>
>
> On Thu, Oct 8, 2009 at 8:38 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
> On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <rnk at mit.edu> wrote:
> > IMO Jeff's solution is the cleanest, simplest way to get code that
> > works.  Just generate a separate function for every barrier in the
> > program, and mark it noinline.  This way the instruction pointers  
> will
> > be unique to the barrier.
>
> No, this gets rather nasty: to support an instruction like this, it
> isn't legal to duplicate calls to functions containing a barrier
> instruction.
>
> Another proposal: add an executebarrier function attribute for
> functions which directly or indirectly contain an execution barrier,
> and adjust all the relevant transformation passes, like jump threading
> and loop unswitching, to avoid duplicating calls to such functions.
> This puts a slight burden on the frontend to mark functions
> appropriately, but I don't see any other solution which doesn't affect
> code which doesn't use execute barriers.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091009/041cdd88/attachment-0001.html 

From eli.friedman at gmail.com  Fri Oct  9 04:22:03 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 9 Oct 2009 02:22:03 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
Message-ID: <f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>

On Fri, Oct 9, 2009 at 12:20 AM, Mon Ping Wang <monping at apple.com> wrote:
>
> The requirement in OpenCL is that all threads (work-items) are required to
> hit the same barrier. ?If one does what you have shown below, it is not
> legal because some threads may go through the block with S1 and some other
> threads will go the other way. ?On some hardware, such a program will cause
> a hardware stall.?If one is inlining, it is preferable to inline early
> assuming the rest of the transformations don't mess with the barrier. Eli is
> correct that you can't duplicate calls to a function containing these kind
> of barriers for the same reasons. ?From the discussions so far, it would be
> nice if such a concept where you don't want to modify the control flow of a
> basic block containing such an execution barrier or a function containing
> such a barrier. This requires that all phases that does such optimizations
> would have to be made aware of it. ?Such a concept may be also useful for
> other things like inline assembly where one may not want to duplicate a
> block.

It's probably worth noting that I wasn't proposing a general
prohibition of duplication; it would be okay for inlining or loop
unrolling to duplicate a call to a function marked executebarrier.
It's not the same sort of prohibition that one might want for inline
assembly.

-Eli


From luoyonggang at gmail.com  Fri Oct  9 05:14:50 2009
From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=)
Date: Fri, 9 Oct 2009 18:14:50 +0800
Subject: [LLVMdev] Hi, everyone, fail on building c-index-test
In-Reply-To: <F8F98CA2-E2F5-49AC-95A9-225C03209747@apple.com>
References: <806065d90910010636g3e5a253fue9bd14be96dd1315@mail.gmail.com>
	<F7F01E8C-CB7D-46D9-B24B-5975AB0C5181@apple.com>
	<806065d90910051517o2cd17551jff5ab9ae20bee93@mail.gmail.com>
	<50EF0731-3436-4F53-B8D5-2347F97EA359@apple.com>
	<806065d90910070757y4d9070echc408cc822760fb95@mail.gmail.com>
	<E723FED7-3680-4F93-8056-194CCE5B2F2F@apple.com>
	<806065d90910070836q59bd0deq563184fafa680b10@mail.gmail.com>
	<F8F98CA2-E2F5-49AC-95A9-225C03209747@apple.com>
Message-ID: <806065d90910090314j6e9451b9j7fd38378d06056b4@mail.gmail.com>

Mmm, do you see that patch? Because the order of those linked library
is incorrect. Mingw can't generate libCindex.dll.
So I midified the likage order.
Also, for the reason of removing duplicated code,  I removed some
unnecessay cmake code.  And add an new cmake function

2009/10/7, Douglas Gregor <dgregor at apple.com>:
>
> On Oct 7, 2009, at 8:36 AM, ???(Yonggang Luo) wrote:
>
>> That does not mean that every library or application built within
>> the LLVM tree must be linked as C++.
>> That's right, so I create an new patch to resolve this problem(Now,
>> it's only when the app link with the llvm library then it's will set
>> the linkage target as CXX, or it's apply the default cmake
>> LINKAGE_LAN), also it's resolved another problem appeared on CIndex/
>> Mingw
>
> What other problem?
>
> 	- Doug

-- 
?????????

         ??
?
???
Yours
    sincerely,
Yonggang Luo


From monping at apple.com  Fri Oct  9 05:34:04 2009
From: monping at apple.com (Mon Ping Wang)
Date: Fri, 9 Oct 2009 03:34:04 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
	<f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>
Message-ID: <27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>


Point taken :->.  Inlining of these functions containing these  
barriers are required on some platforms.  The only restriction is that  
any control flow optimization must preserve the property that all  
threads will hit the same barrier.

-- Mon Ping

On Oct 9, 2009, at 2:22 AM, Eli Friedman wrote:

> On Fri, Oct 9, 2009 at 12:20 AM, Mon Ping Wang <monping at apple.com>  
> wrote:
>>
>> The requirement in OpenCL is that all threads (work-items) are  
>> required to
>> hit the same barrier.  If one does what you have shown below, it is  
>> not
>> legal because some threads may go through the block with S1 and  
>> some other
>> threads will go the other way.  On some hardware, such a program  
>> will cause
>> a hardware stall. If one is inlining, it is preferable to inline  
>> early
>> assuming the rest of the transformations don't mess with the  
>> barrier. Eli is
>> correct that you can't duplicate calls to a function containing  
>> these kind
>> of barriers for the same reasons.  From the discussions so far, it  
>> would be
>> nice if such a concept where you don't want to modify the control  
>> flow of a
>> basic block containing such an execution barrier or a function  
>> containing
>> such a barrier. This requires that all phases that does such  
>> optimizations
>> would have to be made aware of it.  Such a concept may be also  
>> useful for
>> other things like inline assembly where one may not want to  
>> duplicate a
>> block.
>
> It's probably worth noting that I wasn't proposing a general
> prohibition of duplication; it would be okay for inlining or loop
> unrolling to duplicate a call to a function marked executebarrier.
> It's not the same sort of prohibition that one might want for inline
> assembly.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From hvdieren at elis.ugent.be  Fri Oct  9 07:14:51 2009
From: hvdieren at elis.ugent.be (Hans Vandierendonck)
Date: Fri, 9 Oct 2009 14:14:51 +0200
Subject: [LLVMdev] DS-AA reports erroneous NoModRef
Message-ID: <EE3D70A1-B9DF-4FA6-8DFB-0DD5FCFD6F75@elis.ugent.be>

Hi,

I am using DataStructureAA.cpp (poolalloc project) for alias analysis  
purposes and have noticed an error in getModRefInfo(). The situation  
is that Mod/Ref info is called with a CallSite and GlobalVariable  
argument, where the global is passed as an argument to the call.  
Furthermore, the callee function does *nothing* with this global but  
to pass it on to another callee function. In the last callee, the  
BottomUp DSNode is the same as the GlobalGraphs' node (very detailed;  
including a link to another DSNode), but in the top function and the  
intermediate callee, the global is not accessed and its DSNode is  
simply "I", without a type.

An error manifests itself in DataStructureAA, as the intermediate  
function's BottomUp DSNode is used to check for Mod/Ref info (using  
the RangeIt, then isModifiedNode() and isReadNode()). But the  
intermediate function's DSNode is simply "I", so no Mod/Ref is  
reported. This is erroneous; the global is Mod&Ref at the call site.

I am not sure whether there is an error in either ds-aa or in  
BottomUpDSA.

I have reduced the program down to a simpler test case. Here the  
intermediate functions have an "IE" node. The error occurs when trying  
to see if @spec_compress() does Mod/Ref @spec_fd1 (NoModRef reported).  
In contrast, ds-aa correctly reports ModRef on the callsite to  
@spec_putc() in @compressStream().

Kind regards,
Hans.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: testcase-dce.ll
Type: application/octet-stream
Size: 6431 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091009/e218bac5/attachment.obj 
-------------- next part --------------



--  
-------------------------------------------------------------------------------
  Hans Vandierendonck, PhD, Ghent University, Electronics &  
Information Systems
  E-mail: hans.vandierendonck at UGent.be      http://www.elis.UGent.be/~hvdieren/
-------------------------------------------------------------------------------

From andrewl at lenharth.org  Fri Oct  9 07:39:03 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Fri, 9 Oct 2009 07:39:03 -0500
Subject: [LLVMdev] DS-AA reports erroneous NoModRef
In-Reply-To: <EE3D70A1-B9DF-4FA6-8DFB-0DD5FCFD6F75@elis.ugent.be>
References: <EE3D70A1-B9DF-4FA6-8DFB-0DD5FCFD6F75@elis.ugent.be>
Message-ID: <85dfcd7f0910090539u2d9051cwe0336af42cf63f2a@mail.gmail.com>

On Fri, Oct 9, 2009 at 7:14 AM, Hans Vandierendonck
<hvdieren at elis.ugent.be> wrote:
> Hi,

The correctness of ds-aa hasn't been tested in a long time and hasn't
been tested against changes in BottomUp.  ModRef info in general
hasn't been tested for several years, mostly dsa has been used for
it's points-to graph, not the flags.

You might try tracing the inlining with --debug and making sure all
callsites are inlined.

Andrew

> I am using DataStructureAA.cpp (poolalloc project) for alias analysis
> purposes and have noticed an error in getModRefInfo(). The situation is that
> Mod/Ref info is called with a CallSite and GlobalVariable argument, where
> the global is passed as an argument to the call. Furthermore, the callee
> function does *nothing* with this global but to pass it on to another callee
> function. In the last callee, the BottomUp DSNode is the same as the
> GlobalGraphs' node (very detailed; including a link to another DSNode), but
> in the top function and the intermediate callee, the global is not accessed
> and its DSNode is simply "I", without a type.
>
> An error manifests itself in DataStructureAA, as the intermediate function's
> BottomUp DSNode is used to check for Mod/Ref info (using the RangeIt, then
> isModifiedNode() and isReadNode()). But the intermediate function's DSNode
> is simply "I", so no Mod/Ref is reported. This is erroneous; the global is
> Mod&Ref at the call site.
>
> I am not sure whether there is an error in either ds-aa or in BottomUpDSA.
>
> I have reduced the program down to a simpler test case. Here the
> intermediate functions have an "IE" node. The error occurs when trying to
> see if @spec_compress() does Mod/Ref @spec_fd1 (NoModRef reported). In
> contrast, ds-aa correctly reports ModRef on the callsite to @spec_putc() in
> @compressStream().
>
> Kind regards,
> Hans.
>
>
>
>
>
> --
> -------------------------------------------------------------------------------
> ?Hans Vandierendonck, PhD, Ghent University, Electronics & Information
> Systems
> ?E-mail: hans.vandierendonck at UGent.be
> ?http://www.elis.UGent.be/~hvdieren/
> -------------------------------------------------------------------------------
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From stuart at apple.com  Fri Oct  9 10:40:23 2009
From: stuart at apple.com (Stuart Hastings)
Date: Fri, 9 Oct 2009 08:40:23 -0700
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <A0929213-3743-4093-9337-FE441F24C893@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
	<A0929213-3743-4093-9337-FE441F24C893@apple.com>
Message-ID: <2896E598-AED0-49D3-8854-63892F333386@apple.com>


On Oct 8, 2009, at 5:18 PM, Mike Stump wrote:

> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote:
>> Currently, to get LLVM to build "Apple-style," it's necessary to  
>> copy two files (utils/buildit/GNUmakefile and utils/buildit/ 
>> build_llvm) into the top-level directory.
>
> Why not:
>
> $ RC_ARCHS="x86" make
> echo Apple Build.
> Apple Build.
> $ make
> echo Standard Build
> Standard Build
> $ cat Makefile
> ifneq ($(RC_ARCHS),)
> include Makefile.apple
> else
> all:
> 	echo Standard Build
> endif
> mrs $ cat Makefile.apple
> all:
> 	echo Apple Build.
>
> It leaves Makefile mostly alone, all except for three lines at the  
> top and one line at the end of it.

Because the existing top-level Makefile includes "Makefile.config".   
In a normal build, the configure step creates "Makefile.config".   
"Apple-style" builds don't run the configure script (I have filed a  
bug about this :-).

stuart

From timo.lindfors at iki.fi  Fri Oct  9 12:31:17 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Fri, 09 Oct 2009 20:31:17 +0300
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
	(Terence P. Kelly's message of "Thu, 8 Oct 2009 22:26:18 +0000")
References: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
Message-ID: <84y6nkbhju.fsf@sauna.l.org>

"Kelly, Terence P (HP Labs Researcher)" <terence.p.kelly at hp.com> writes:
> and I'm wondering if anyone else has, or if
> anyone can think of situations where it will
> fail.

This will fail when the input files are temporary files that are
removed after the build process. You will also be building the program
twice.

http://saturn.stanford.edu/pages/relatedindex.html folks do something
similar but only look at the build log.


From jyasskin at google.com  Fri Oct  9 12:46:40 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Fri, 9 Oct 2009 10:46:40 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
	<f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>
	<27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>
Message-ID: <bb55930e0910091046m6729f5c2l610afda6a3b16398@mail.gmail.com>

Are the platforms with no function calls the same ones that have
optimization-hostile barrier instructions? If the two sets of
platforms are disjoint, OpenCL implementers can use my or Devang's
noinline-function technique on the optimization-hostile platforms, and
inject a unique argument into the barrier() call in the frontend on
the no-function platforms.

On Fri, Oct 9, 2009 at 3:34 AM, Mon Ping Wang <monping at apple.com> wrote:
>
> Point taken :->. ?Inlining of these functions containing these
> barriers are required on some platforms. ?The only restriction is that
> any control flow optimization must preserve the property that all
> threads will hit the same barrier.
>
> -- Mon Ping
>
> On Oct 9, 2009, at 2:22 AM, Eli Friedman wrote:
>
>> On Fri, Oct 9, 2009 at 12:20 AM, Mon Ping Wang <monping at apple.com>
>> wrote:
>>>
>>> The requirement in OpenCL is that all threads (work-items) are
>>> required to
>>> hit the same barrier. ?If one does what you have shown below, it is
>>> not
>>> legal because some threads may go through the block with S1 and
>>> some other
>>> threads will go the other way. ?On some hardware, such a program
>>> will cause
>>> a hardware stall. If one is inlining, it is preferable to inline
>>> early
>>> assuming the rest of the transformations don't mess with the
>>> barrier. Eli is
>>> correct that you can't duplicate calls to a function containing
>>> these kind
>>> of barriers for the same reasons. ?From the discussions so far, it
>>> would be
>>> nice if such a concept where you don't want to modify the control
>>> flow of a
>>> basic block containing such an execution barrier or a function
>>> containing
>>> such a barrier. This requires that all phases that does such
>>> optimizations
>>> would have to be made aware of it. ?Such a concept may be also
>>> useful for
>>> other things like inline assembly where one may not want to
>>> duplicate a
>>> block.
>>
>> It's probably worth noting that I wasn't proposing a general
>> prohibition of duplication; it would be okay for inlining or loop
>> unrolling to duplicate a call to a function marked executebarrier.
>> It's not the same sort of prohibition that one might want for inline
>> assembly.
>>
>> -Eli
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From monping at apple.com  Fri Oct  9 13:06:25 2009
From: monping at apple.com (Mon Ping Wang)
Date: Fri, 9 Oct 2009 11:06:25 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <bb55930e0910091046m6729f5c2l610afda6a3b16398@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com>
	<493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
	<f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>
	<27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>
	<bb55930e0910091046m6729f5c2l610afda6a3b16398@mail.gmail.com>
Message-ID: <F0909DB4-26EB-42F3-9B45-86B0E1BAD291@apple.com>


Yes, this is the case.   The platforms I'm thinking of don't support  
function calls and have the optimization-hostile barrier instructions.

   -- Mon Ping



On Oct 9, 2009, at 10:46 AM, Jeffrey Yasskin wrote:

> Are the platforms with no function calls the same ones that have
> optimization-hostile barrier instructions? If the two sets of
> platforms are disjoint, OpenCL implementers can use my or Devang's
> noinline-function technique on the optimization-hostile platforms, and
> inject a unique argument into the barrier() call in the frontend on
> the no-function platforms.
>
> On Fri, Oct 9, 2009 at 3:34 AM, Mon Ping Wang <monping at apple.com>  
> wrote:
>>
>> Point taken :->.  Inlining of these functions containing these
>> barriers are required on some platforms.  The only restriction is  
>> that
>> any control flow optimization must preserve the property that all
>> threads will hit the same barrier.
>>
>> -- Mon Ping
>>
>> On Oct 9, 2009, at 2:22 AM, Eli Friedman wrote:
>>
>>> On Fri, Oct 9, 2009 at 12:20 AM, Mon Ping Wang <monping at apple.com>
>>> wrote:
>>>>
>>>> The requirement in OpenCL is that all threads (work-items) are
>>>> required to
>>>> hit the same barrier.  If one does what you have shown below, it is
>>>> not
>>>> legal because some threads may go through the block with S1 and
>>>> some other
>>>> threads will go the other way.  On some hardware, such a program
>>>> will cause
>>>> a hardware stall. If one is inlining, it is preferable to inline
>>>> early
>>>> assuming the rest of the transformations don't mess with the
>>>> barrier. Eli is
>>>> correct that you can't duplicate calls to a function containing
>>>> these kind
>>>> of barriers for the same reasons.  From the discussions so far, it
>>>> would be
>>>> nice if such a concept where you don't want to modify the control
>>>> flow of a
>>>> basic block containing such an execution barrier or a function
>>>> containing
>>>> such a barrier. This requires that all phases that does such
>>>> optimizations
>>>> would have to be made aware of it.  Such a concept may be also
>>>> useful for
>>>> other things like inline assembly where one may not want to
>>>> duplicate a
>>>> block.
>>>
>>> It's probably worth noting that I wasn't proposing a general
>>> prohibition of duplication; it would be okay for inlining or loop
>>> unrolling to duplicate a call to a function marked executebarrier.
>>> It's not the same sort of prohibition that one might want for inline
>>> assembly.
>>>
>>> -Eli
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From sricketts at maxentric.com  Fri Oct  9 13:06:59 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Fri, 9 Oct 2009 11:06:59 -0700
Subject: [LLVMdev] Detecting reduction operations
Message-ID: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>

I want to be able to detect reduction operations using a method
similar to that described here:

http://portal.acm.org/citation.cfm?id=237578.237581

(I am open to other suggestions if there is a better technique).

I am curious if anyone has done this with LLVM or if there are and
recommendations for where to start with my implementation. I am only
interested in identifying the reductions -- I will not need to do any
kind of transformation to exploit the parallelism. However, if this
sort of work might be useful to others, I can try to generalize the
interface based on any suggestions in case my work gets to the point
where it could be checked in.

Scott

From Micah.Villmow at amd.com  Fri Oct  9 13:24:15 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Fri, 9 Oct 2009 11:24:15 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com><f5aa3e9b0910071749r3b4172c1vb145cf1ff0a08989@mail.gmail.com><493720826E33B1459E7F5C253E6D4BB58D7BC1@ssanexmb2.amd.com><bb55930e0910081108ra33936bwcf6667697c958e35@mail.gmail.com><493720826E33B1459E7F5C253E6D4BB58D7BDB@ssanexmb2.amd.com><352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com><9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com><f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D7DAC@ssanexmb2.amd.com>

Vinod,

 Depends on your reading of the spec. It states that if a work-item goes
down a conditional path then all work-items in a work-group must also go
down the conditional path. So in my interpretation, the call to
user_func() in the true branch produces a different barrier during
execution than the call to user_func() in the false branch, even though
they both exist on the same line of source.

 

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Vinod Grover
Sent: Thursday, October 08, 2009 11:18 PM
To: Eli Friedman
Cc: Reid Kleckner; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Instructions that cannot be duplicated

 

Is inlining (which duplicates code) of functions containing OpenCL style
barriers legal?

or e.g. 

 

if you had some changed phase ordering where you had

 

if (cond) {

   S1;

}

call user_func() // user_func has a barrier buried inside it.

 

you do tail splitting

 

if (cond) {

   S1; 

   call user_func()

} else {

   call user_func();

}

 

now you inline -- oops now you might have a problem

 

so do you want IPA to propagate the barrier bit to the call sites?

 

you could do inlining before tail splitting

 

sounds messy...

 

Vinod

 

On Thu, Oct 8, 2009 at 8:38 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:

On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <rnk at mit.edu> wrote:
> IMO Jeff's solution is the cleanest, simplest way to get code that
> works.  Just generate a separate function for every barrier in the
> program, and mark it noinline.  This way the instruction pointers will
> be unique to the barrier.

No, this gets rather nasty: to support an instruction like this, it
isn't legal to duplicate calls to functions containing a barrier
instruction.

Another proposal: add an executebarrier function attribute for
functions which directly or indirectly contain an execution barrier,
and adjust all the relevant transformation passes, like jump threading
and loop unswitching, to avoid duplicating calls to such functions.
This puts a slight burden on the frontend to mark functions
appropriately, but I don't see any other solution which doesn't affect
code which doesn't use execute barriers.

-Eli


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091009/1e158490/attachment.html 

From devang.patel at gmail.com  Fri Oct  9 13:33:56 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Fri, 9 Oct 2009 11:33:56 -0700
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <F0909DB4-26EB-42F3-9B45-86B0E1BAD291@apple.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com>
	<352a1fb20910081259s7b3bb378hc78252ab1b576e31@mail.gmail.com>
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com>
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com>
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com>
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
	<f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com>
	<27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>
	<bb55930e0910091046m6729f5c2l610afda6a3b16398@mail.gmail.com>
	<F0909DB4-26EB-42F3-9B45-86B0E1BAD291@apple.com>
Message-ID: <352a1fb20910091133w1bdb85a4gb8185bdb03d693aa@mail.gmail.com>

On Fri, Oct 9, 2009 at 11:06 AM, Mon Ping Wang <monping at apple.com> wrote:
>
> Yes, this is the case. ? The platforms I'm thinking of don't support
> function calls and have the optimization-hostile barrier instructions.
>
> ? -- Mon Ping


How about you do two stage inlining for such platforms ?

1. Inline everything except barrier functions
2. Apply usual transformations
3. Inline barrier functions

-
Devang


From rnk at mit.edu  Fri Oct  9 13:52:48 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Fri, 9 Oct 2009 14:52:48 -0400
Subject: [LLVMdev] Instructions that cannot be duplicated
In-Reply-To: <352a1fb20910091133w1bdb85a4gb8185bdb03d693aa@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D79E4@ssanexmb2.amd.com> 
	<9a9942200910081411u52332453q5a3b10b12b16158@mail.gmail.com> 
	<f5aa3e9b0910082038r4dfa4b3cj7c7bf86bc5ff963d@mail.gmail.com> 
	<35657f570910082317l28077e92ue3e65554ee38dcd@mail.gmail.com> 
	<A0EF8D78-05B6-423C-ABD9-B4EA101E1117@apple.com>
	<f5aa3e9b0910090222l37932cfdq80bb1424f6e54951@mail.gmail.com> 
	<27322B9C-2D7E-4634-A4D2-742151F62766@apple.com>
	<bb55930e0910091046m6729f5c2l610afda6a3b16398@mail.gmail.com> 
	<F0909DB4-26EB-42F3-9B45-86B0E1BAD291@apple.com>
	<352a1fb20910091133w1bdb85a4gb8185bdb03d693aa@mail.gmail.com>
Message-ID: <9a9942200910091152k17ae7964vaf0811ba6b9ca18d@mail.gmail.com>

If the call to the noinline function was duplicated, when you did the
final inline to multiple locations, you would have duplicated the
original barrier instruction.

Reid

On Fri, Oct 9, 2009 at 2:33 PM, Devang Patel <devang.patel at gmail.com> wrote:
> On Fri, Oct 9, 2009 at 11:06 AM, Mon Ping Wang <monping at apple.com> wrote:
>>
>> Yes, this is the case. ? The platforms I'm thinking of don't support
>> function calls and have the optimization-hostile barrier instructions.
>>
>> ? -- Mon Ping
>
>
> How about you do two stage inlining for such platforms ?
>
> 1. Inline everything except barrier functions
> 2. Apply usual transformations
> 3. Inline barrier functions
>
> -
> Devang
>


From mrs at apple.com  Fri Oct  9 14:34:25 2009
From: mrs at apple.com (Mike Stump)
Date: Fri, 9 Oct 2009 12:34:25 -0700
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <2896E598-AED0-49D3-8854-63892F333386@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
	<A0929213-3743-4093-9337-FE441F24C893@apple.com>
	<2896E598-AED0-49D3-8854-63892F333386@apple.com>
Message-ID: <E9913FC3-B4C3-4264-8EFF-328E2B4C4CC4@apple.com>


On Oct 9, 2009, at 8:40 AM, Stuart Hastings wrote:

>
> On Oct 8, 2009, at 5:18 PM, Mike Stump wrote:
>
>> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote:
>>> Currently, to get LLVM to build "Apple-style," it's necessary to  
>>> copy two files (utils/buildit/GNUmakefile and utils/buildit/ 
>>> build_llvm) into the top-level directory.
>>
>> Why not:
>>
>> $ RC_ARCHS="x86" make
>> echo Apple Build.
>> Apple Build.
>> $ make
>> echo Standard Build
>> Standard Build
>> $ cat Makefile
>> ifneq ($(RC_ARCHS),)
>> include Makefile.apple
>> else
>> all:
>> 	echo Standard Build
>> endif
>> mrs $ cat Makefile.apple
>> all:
>> 	echo Apple Build.
>>
>> It leaves Makefile mostly alone, all except for three lines at the  
>> top and one line at the end of it.
>
> Because the existing top-level Makefile includes "Makefile.config".

?  Only if you want it:

$ cat Makefile
ifdef FOO
include no_such_file
endif


all:
	echo ok
mrs $ make all
echo ok
ok

From dag at cray.com  Fri Oct  9 15:26:52 2009
From: dag at cray.com (David Greene)
Date: Fri, 9 Oct 2009 15:26:52 -0500
Subject: [LLVMdev] Help with gcc SSE intrinsics
Message-ID: <200910091526.52666.dag@cray.com>

Ok, I've been looking at this for hours and can't figure it out.  I know I'm 
missing something obvious.

I've been spending the past few days beefing up the vector support in the C
Backend.  This should help us debug vector code that's miscompiled.  But
gcc doesn't like this fragment:

  ((double *)(&llvm_cbe_r1147))[0u] = 
(((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 = 4ull, 
llvm_cbe_r1146__BITCAST_TEMPORARY .Double)));
  llvm_cbe_r1148 = __builtin_ia32_movddup(llvm_cbe_r1147);

prog.linked.c:10393: error: incompatible types when assigning to type 'double 
__vector__'
 from type 'int'

  double  __attribute__((vector_size(16 ))) llvm_cbe_r1147;
  double  __attribute__((vector_size(16 ))) llvm_cbe_r1148;

Any ideas what gcc is complaining about?  I'm running gcc with -msse3.

                            -Dave

From dag at cray.com  Fri Oct  9 15:45:22 2009
From: dag at cray.com (David Greene)
Date: Fri, 9 Oct 2009 15:45:22 -0500
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <A0929213-3743-4093-9337-FE441F24C893@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
	<A0929213-3743-4093-9337-FE441F24C893@apple.com>
Message-ID: <200910091545.23204.dag@cray.com>

On Thursday 08 October 2009 19:18, Mike Stump wrote:
> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote:
> > Currently, to get LLVM to build "Apple-style," it's necessary to
> > copy two files (utils/buildit/GNUmakefile and utils/buildit/
> > build_llvm) into the top-level directory.
>
> Why not:
>

> It leaves Makefile mostly alone, all except for three lines at the top
> and one line at the end of it.

Absolutely.  Third-party build systems should impact the public LLVM as little 
as possible.

                                  -Dave

From daveed at vandevoorde.com  Fri Oct  9 15:47:08 2009
From: daveed at vandevoorde.com (David Vandevoorde)
Date: Fri, 9 Oct 2009 16:47:08 -0400
Subject: [LLVMdev] Help with gcc SSE intrinsics
In-Reply-To: <200910091526.52666.dag@cray.com>
References: <200910091526.52666.dag@cray.com>
Message-ID: <A1C8E7B0-7E4B-481D-B4BD-3885FA10908E@vandevoorde.com>


On Oct 9, 2009, at 4:26 PM, David Greene wrote:

> Ok, I've been looking at this for hours and can't figure it out.  I  
> know I'm
> missing something obvious.
>
> I've been spending the past few days beefing up the vector support  
> in the C
> Backend.  This should help us debug vector code that's miscompiled.   
> But
> gcc doesn't like this fragment:
>
>  ((double *)(&llvm_cbe_r1147))[0u] =
> (((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 = 4ull,
> llvm_cbe_r1146__BITCAST_TEMPORARY .Double)));
>  llvm_cbe_r1148 = __builtin_ia32_movddup(llvm_cbe_r1147);
>
> prog.linked.c:10393: error: incompatible types when assigning to  
> type 'double
> __vector__'
> from type 'int'
>
>  double  __attribute__((vector_size(16 ))) llvm_cbe_r1147;
>  double  __attribute__((vector_size(16 ))) llvm_cbe_r1148;
>
> Any ideas what gcc is complaining about?  I'm running gcc with -msse3.


As far as I can tell, GCC 4.x no longer predeclares  
__builtin_ia32_movddup.  g++ gives a clearer error, but in C the  
function is implicitly declared as a returning int (because of the  
call), and so you get the type mismatch again.

At least, that's my guess (I'm not familiar with GCC internals).

	Daveed


From dalej at apple.com  Fri Oct  9 15:47:34 2009
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 9 Oct 2009 13:47:34 -0700
Subject: [LLVMdev] Help with gcc SSE intrinsics
In-Reply-To: <200910091526.52666.dag@cray.com>
References: <200910091526.52666.dag@cray.com>
Message-ID: <D2DEC54E-F9B1-41D4-9A63-AB4CA33E0991@apple.com>


On Oct 9, 2009, at 1:26 PMPDT, David Greene wrote:

> Ok, I've been looking at this for hours and can't figure it out.  I  
> know I'm
> missing something obvious.
>
> I've been spending the past few days beefing up the vector support  
> in the C
> Backend.  This should help us debug vector code that's miscompiled.   
> But
> gcc doesn't like this fragment:
>
>  ((double *)(&llvm_cbe_r1147))[0u] =
> (((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 = 4ull,
> llvm_cbe_r1146__BITCAST_TEMPORARY .Double)));
>  llvm_cbe_r1148 = __builtin_ia32_movddup(llvm_cbe_r1147);

I don't see __builtin_ia32_movddup defined anywhere in the llvm-gcc  
sources.  That's probably it.

> prog.linked.c:10393: error: incompatible types when assigning to  
> type 'double
> __vector__'
> from type 'int'
>
>  double  __attribute__((vector_size(16 ))) llvm_cbe_r1147;
>  double  __attribute__((vector_size(16 ))) llvm_cbe_r1148;
>
> Any ideas what gcc is complaining about?  I'm running gcc with -msse3.
>
>                            -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From dag at cray.com  Fri Oct  9 15:50:03 2009
From: dag at cray.com (David Greene)
Date: Fri, 9 Oct 2009 15:50:03 -0500
Subject: [LLVMdev] Help with gcc SSE intrinsics
In-Reply-To: <D2DEC54E-F9B1-41D4-9A63-AB4CA33E0991@apple.com>
References: <200910091526.52666.dag@cray.com>
	<D2DEC54E-F9B1-41D4-9A63-AB4CA33E0991@apple.com>
Message-ID: <200910091550.03806.dag@cray.com>

On Friday 09 October 2009 15:47, Dale Johannesen wrote:
> On Oct 9, 2009, at 1:26 PMPDT, David Greene wrote:
> > Ok, I've been looking at this for hours and can't figure it out.  I
> > know I'm
> > missing something obvious.
> >
> > I've been spending the past few days beefing up the vector support
> > in the C
> > Backend.  This should help us debug vector code that's miscompiled.
> > But
> > gcc doesn't like this fragment:
> >
> >  ((double *)(&llvm_cbe_r1147))[0u] =
> > (((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 = 4ull,
> > llvm_cbe_r1146__BITCAST_TEMPORARY .Double)));
> >  llvm_cbe_r1148 = __builtin_ia32_movddup(llvm_cbe_r1147);
>
> I don't see __builtin_ia32_movddup defined anywhere in the llvm-gcc
> sources.  That's probably it.

Not llvm-gcc.  GNU gcc.  It's documented here:

http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions

                                 -Dave

From clattner at apple.com  Fri Oct  9 15:52:28 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 9 Oct 2009 13:52:28 -0700
Subject: [LLVMdev] question on code in PointerIntPair.h
In-Reply-To: <87bpkhpyg7.fsf@cuma.i-did-not-set--mail-host-address--so-tickle-me>
References: <87bpkhpyg7.fsf@cuma.i-did-not-set--mail-host-address--so-tickle-me>
Message-ID: <FF9F4D1C-72E6-4592-9B98-CB1B5D1E5390@apple.com>


On Oct 8, 2009, at 10:50 AM, Maurizio Vitale wrote:

> around line 45 a bitmask is computed as:
>
>    PointerBitMask =
>      ~(uintptr_t)(((intptr_t)1 << PtrTraits::NumLowBitsAvailable)-1),
>
> my question is why is the shift performed on intptr_t? Wouldn't the
> following be ok?
>
>    PointerBitMask =
>      ~(((uintptr_t)1 << PtrTraits::NumLowBitsAvailable)-1),

Hi Maurizio, why do you ask?  Is the existing code causing a problem?

-Chris

From dalej at apple.com  Fri Oct  9 15:57:20 2009
From: dalej at apple.com (Dale Johannesen)
Date: Fri, 9 Oct 2009 13:57:20 -0700
Subject: [LLVMdev] Help with gcc SSE intrinsics
In-Reply-To: <200910091550.03806.dag@cray.com>
References: <200910091526.52666.dag@cray.com>
	<D2DEC54E-F9B1-41D4-9A63-AB4CA33E0991@apple.com>
	<200910091550.03806.dag@cray.com>
Message-ID: <DA9C69E2-F9E0-40B7-BC50-3137480CB957@apple.com>


On Oct 9, 2009, at 1:50 PMPDT, David Greene wrote:

> On Friday 09 October 2009 15:47, Dale Johannesen wrote:
>> On Oct 9, 2009, at 1:26 PMPDT, David Greene wrote:
>>> Ok, I've been looking at this for hours and can't figure it out.  I
>>> know I'm
>>> missing something obvious.
>>>
>>> I've been spending the past few days beefing up the vector support
>>> in the C
>>> Backend.  This should help us debug vector code that's miscompiled.
>>> But
>>> gcc doesn't like this fragment:
>>>
>>> ((double *)(&llvm_cbe_r1147))[0u] =
>>> (((llvm_cbe_r1146__BITCAST_TEMPORARY.Int64 = 4ull,
>>> llvm_cbe_r1146__BITCAST_TEMPORARY .Double)));
>>> llvm_cbe_r1148 = __builtin_ia32_movddup(llvm_cbe_r1147);
>>
>> I don't see __builtin_ia32_movddup defined anywhere in the llvm-gcc
>> sources.  That's probably it.
>
> Not llvm-gcc.  GNU gcc.  It's documented here:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions

I see, I'm not in a position to duplicate this then.  Good luck.


From maurizio.vitale at polymath-solutions.com  Fri Oct  9 16:02:59 2009
From: maurizio.vitale at polymath-solutions.com (Maurizio Vitale)
Date: Fri, 09 Oct 2009 17:02:59 -0400
Subject: [LLVMdev] question on code in PointerIntPair.h
In-Reply-To: <FF9F4D1C-72E6-4592-9B98-CB1B5D1E5390@apple.com> (Chris Lattner's
	message of "Fri, 9 Oct 2009 13:52:28 -0700")
References: <87bpkhpyg7.fsf@cuma.i-did-not-set--mail-host-address--so-tickle-me>
	<FF9F4D1C-72E6-4592-9B98-CB1B5D1E5390@apple.com>
Message-ID: <873a5smgak.fsf@polymath-solutions.com>

>>>>> "Chris" == Chris Lattner <clattner at apple.com> writes:

    Chris> On Oct 8, 2009, at 10:50 AM, Maurizio Vitale wrote:

> around line 45 a bitmask is computed as:
    >> 
    >> PointerBitMask = ~(uintptr_t)(((intptr_t)1 <<
    >> PtrTraits::NumLowBitsAvailable)-1),
    >> 
    >> my question is why is the shift performed on intptr_t? Wouldn't
    >> the following be ok?
    >> 
    >> PointerBitMask = ~(((uintptr_t)1 <<
    >> PtrTraits::NumLowBitsAvailable)-1),

    Chris> Hi Maurizio, why do you ask?  Is the existing code causing a
    Chris> problem?

Not at all (I'm not really a llvm/clang user yet, only an interested
observer).

The reason is that this particular file has been mentioned on the boost
developer mailing list in a thread on compressed pointers/integer
pairs. 

I'm working on bringing some code of mine up to boost standards for a
review and I was tracking down all things in that thread.

I noticed thatyou were doing things differently from me and I was
wandering if there was a reason that I couldn't see.

Are you aware of a reason?

TIA,
        
        Maurizio
-- 

From clattner at apple.com  Fri Oct  9 16:05:40 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 9 Oct 2009 14:05:40 -0700
Subject: [LLVMdev] question on code in PointerIntPair.h
In-Reply-To: <873a5smgak.fsf@polymath-solutions.com>
References: <87bpkhpyg7.fsf@cuma.i-did-not-set--mail-host-address--so-tickle-me>
	<FF9F4D1C-72E6-4592-9B98-CB1B5D1E5390@apple.com>
	<873a5smgak.fsf@polymath-solutions.com>
Message-ID: <97DADAFA-C0AA-4591-AC23-FA8E5C536E93@apple.com>


On Oct 9, 2009, at 2:02 PM, Maurizio Vitale wrote:

>>>>>> "Chris" == Chris Lattner <clattner at apple.com> writes:
>
>    Chris> On Oct 8, 2009, at 10:50 AM, Maurizio Vitale wrote:
>
>> around line 45 a bitmask is computed as:
>>>
>>> PointerBitMask = ~(uintptr_t)(((intptr_t)1 <<
>>> PtrTraits::NumLowBitsAvailable)-1),
>>>
>>> my question is why is the shift performed on intptr_t? Wouldn't
>>> the following be ok?
>>>
>>> PointerBitMask = ~(((uintptr_t)1 <<
>>> PtrTraits::NumLowBitsAvailable)-1),
>
>    Chris> Hi Maurizio, why do you ask?  Is the existing code causing a
>    Chris> problem?
>
> Not at all (I'm not really a llvm/clang user yet, only an interested
> observer).
>
> The reason is that this particular file has been mentioned on the  
> boost
> developer mailing list in a thread on compressed pointers/integer
> pairs.
>
> I'm working on bringing some code of mine up to boost standards for a
> review and I was tracking down all things in that thread.
>
> I noticed thatyou were doing things differently from me and I was
> wandering if there was a reason that I couldn't see.

They seem equivalent to me.

-Chris

From echristo at apple.com  Fri Oct  9 17:30:18 2009
From: echristo at apple.com (Eric Christopher)
Date: Fri, 9 Oct 2009 15:30:18 -0700
Subject: [LLVMdev] Is ExecutionEngine always meant to be a singleton?
In-Reply-To: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com>
References: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com>
Message-ID: <8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>


On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote:

> Right now, on X86, creating multiple ExecutionEngines in the same
> process causes an assertion.
>

Yes. This is by design.

> If it's supposed to always be a singleton, should there be a way to
> get the process's ExecutionEngine instance?
>

I can't see why. You could make a server to process llvm code.

> This would, among other things, allow "lli" to execute bitcode that
> itself uses the ExecutionEngine.

I think you're doing something a bit fishy here. I'm not sure how  
you're generating code, but you may want to look at Unladen Swallow or  
Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is  
generally used for jitting, and jitting in general.

-eric

From rnk at mit.edu  Fri Oct  9 18:03:01 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Fri, 9 Oct 2009 19:03:01 -0400
Subject: [LLVMdev] Is ExecutionEngine always meant to be a singleton?
In-Reply-To: <8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
References: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com> 
	<8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
Message-ID: <9a9942200910091603t2c400e09v9ee4f66ec72126cc@mail.gmail.com>

>> This would, among other things, allow "lli" to execute bitcode that
>> itself uses the ExecutionEngine.
>
> I think you're doing something a bit fishy here. I'm not sure how
> you're generating code, but you may want to look at Unladen Swallow or
> Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is
> generally used for jitting, and jitting in general.

Really?  This seems like a perfectly reasonable thing to want to do.
Why shouldn't I be able to JIT a JIT?  Run lli inside lli.  If you
read his other mail, Kenneth is trying to support code that can
execute at compile time that might generate more code.  So the code
needs a way to interact with the compiler, ie the EE, and invoke it on
more bitcode.

Currently there is a JIT *TheJIT static global inside JITEmitter.cpp
which you could expose, if you wanted to.  Alternatively, if LLVM
doesn't want to expose the singleton-ness of the JIT as part of the
API, you can have a single global on your side.

Reid

From dag at cray.com  Fri Oct  9 18:29:17 2009
From: dag at cray.com (David Greene)
Date: Fri, 9 Oct 2009 18:29:17 -0500
Subject: [LLVMdev] Help with gcc SSE intrinsics
In-Reply-To: <200910091550.03806.dag@cray.com>
References: <200910091526.52666.dag@cray.com>
	<D2DEC54E-F9B1-41D4-9A63-AB4CA33E0991@apple.com>
	<200910091550.03806.dag@cray.com>
Message-ID: <200910091829.17817.dag@cray.com>

On Friday 09 October 2009 15:50, David Greene wrote:

> Not llvm-gcc.  GNU gcc.  It's documented here:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/X86-Built_002din-Functions.html
>#X86-Built_002din-Functions

Aha!  They removed this intrinsic and expect everyone to know to use the
Intel one: _mm_movedup_pd.

Grr...

On the plus side, the CBE is now rockin' with vector code.  I'm seeing some
truly weird...err...stuff.  :)

                           -Dave

From idadesub at users.sourceforge.net  Fri Oct  9 18:56:42 2009
From: idadesub at users.sourceforge.net (Erick Tryzelaar)
Date: Fri, 9 Oct 2009 16:56:42 -0700
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910080520h4844ecc7o531bcd6c01a5a729@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com> 
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com> 
	<1ef034530910080039s30ee5d18sb2847b94001804b9@mail.gmail.com> 
	<400d33ea0910080520h4844ecc7o531bcd6c01a5a729@mail.gmail.com>
Message-ID: <1ef034530910091656h7a38449fn75fbbc51c5f254ed@mail.gmail.com>

On Thu, Oct 8, 2009 at 5:20 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>
> Thanks. ?Let me start by talking a bit about my project.
>
> I'm working on a compiler/language that supports run-time code
> generation and compile-time code execution. ?Besides the obvious
> benefits of easier JITting, I also get the benefits of C++ templates
> and metaprogramming without all of the headaches.
>
> To make this work, the compiler actually compiles functions down into
> function generators, outputting calls to the LLVM C-bindings that
> generate a "regular" function. ?The programmer can then either leave
> them in that form for run-time JITting, or have the compiler JIT and
> execute those function generators in order to get "regular" functions.
> ?Either or both can be exposed as public functions and left in place
> by the optimizer. ?The function generator gets its own set of
> parameters, and multiple functions with variations can be generated at
> compile time or runtime.
>
> He can also put compile-time expressions inside the body of functions,
> so that when the function generator runs, the compile-time expressions
> are evaluated and used for function generation. ?Those compile-time
> expressions can use global variables and/or the function generator
> parameters..
>
> Anyway, this scheme means that extensive LLVM capability needs to be
> available to generated code, since it's the generated code that
> creates all of the "regular" functions. ?Generated code has a much
> easier time calling the C bindings than the C++ API.


You're already doing something a bit more complicated than me :) This
does seem a bit more advanced than what llvm-c is intended for,
though. Is there a reason why you can't make a C++ library to do all
this advanced stuff, and just expose some C hooks for your generated
code?


> I'm using it to support renaming functions and still allowing
> generated code to look up those functions by name; basically searching
> for all global strings containing the function name, and replacing all
> uses of them with uses of the new function name.
>
> I would like to do away with that, though, but I haven't quite managed
> to get rid of all cases where LLVMGetNamedFunction is called by
> generated code.
>
> Also, I've gotten the impression from other developers that the
> C-bindings are considered incomplete and that there is a general
> desire to expose more functionality, and eventually all LLVM
> functionality, through them.


While it's lacking in some areas, it's intentional that not all of
llvm is exposed through llvm-c. I learned that after my patches to
expose APInt/APFloat were turned down :) Llvm's a large object
oriented project, and maintaining a mapping between the c and c++ api
would be pretty challenging, especially since llvm promises to never
remove anything from llvm-c until 3.0. In order to ease development,
it's really designed to just provide the minimum interface for getting
data into llvm. If you want to do something advanced like modify the
bytecode, you really should be writing against the c++ api.


> This supports the "address-of" operator. ?Any Value that is a LoadInst
> can have its address taken. ?I need the pointer operand of the
> LoadInst to get the address Value.
>
> I figured GetOperand was a good starting point, and could support most
> of the operand use cases out there.


I'm not sure if I understand. The load instruction takes an address as
an argument and stores the value into a register, therefore you must
already have the address already. Or am I misinterpreting what you're
saying?


> When I've parsed an int literal and put it on my evaluation stack as a
> Value, there's a case where I need to get it back as an int.
> Specifically, the LLVMBuildExtractValue function requires an int, not
> a Constant, to represent the member. ?I believe that GEP does as well
> when applied to a struct.


GEP doesn't need to take a constant to work.

%0 = alloca { i32, i32 }
%1 = alloca i32
store i32 0, %1
%2 = load %1
%3 = getelementptr { i32, i32 }*, i32 0, %2
%4 = load %3

extractvalue should only be used if you're using value arrays or
structs, and you need to statically know the indexes. If you don't,
then you really should be using GEPs and let the optimizations do
their thing.


> In order to do away with include files, I'm supporting importing
> modules in bitcode form. ?To call a function from an imported module,
> I need to put an external into the compiled module, and it really
> ought to have the same function and argument attributes as the
> original. ?And I want to be able to do that while JITting at runtime
> as well.


If I understand correctly, why aren't the functions already marked
external? If they aren't then an optimizer could theoretically
optimize them away. It may also be more appropriate to pass the
function information through some different channel by the frontend,
rather than directly processing the bytecode. Anyone else have any
experience with doing this?


From kennethuil at gmail.com  Fri Oct  9 19:38:48 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Fri, 9 Oct 2009 19:38:48 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <1ef034530910091656h7a38449fn75fbbc51c5f254ed@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<1ef034530910080039s30ee5d18sb2847b94001804b9@mail.gmail.com>
	<400d33ea0910080520h4844ecc7o531bcd6c01a5a729@mail.gmail.com>
	<1ef034530910091656h7a38449fn75fbbc51c5f254ed@mail.gmail.com>
Message-ID: <400d33ea0910091738m2f473acal83220b61a00bbe36@mail.gmail.com>

On Fri, Oct 9, 2009 at 6:56 PM, Erick Tryzelaar
<idadesub at users.sourceforge.net> wrote:
>
> You're already doing something a bit more complicated than me :) This
> does seem a bit more advanced than what llvm-c is intended for,
> though. Is there a reason why you can't make a C++ library to do all
> this advanced stuff, and just expose some C hooks for your generated
> code?

I suppose not.  It seemed easier for me and advanageous for y'all for
me to get these functions added.  But I can ship my own bridge library
as part of my stdlib.

>
>
>> I'm using it to support renaming functions and still allowing
>> generated code to look up those functions by name; basically searching
>> for all global strings containing the function name, and replacing all
>> uses of them with uses of the new function name.
>>
>> I would like to do away with that, though, but I haven't quite managed
>> to get rid of all cases where LLVMGetNamedFunction is called by
>> generated code.
>>
>> Also, I've gotten the impression from other developers that the
>> C-bindings are considered incomplete and that there is a general
>> desire to expose more functionality, and eventually all LLVM
>> functionality, through them.
>
>
> While it's lacking in some areas, it's intentional that not all of
> llvm is exposed through llvm-c. I learned that after my patches to
> expose APInt/APFloat were turned down :) Llvm's a large object
> oriented project, and maintaining a mapping between the c and c++ api
> would be pretty challenging, especially since llvm promises to never
> remove anything from llvm-c until 3.0. In order to ease development,
> it's really designed to just provide the minimum interface for getting
> data into llvm. If you want to do something advanced like modify the
> bytecode, you really should be writing against the c++ api.

Then the assumptions under which I submitted the patch were wrong.  I
guess it does make sense to ship my own bridge library, then.
Actually, it might be better for me to compile it with llvm-gcc and
ship it as bitcode, come to think of it... one more place that the
optimizer can do its thing.

>
>
>> This supports the "address-of" operator. ?Any Value that is a LoadInst
>> can have its address taken. ?I need the pointer operand of the
>> LoadInst to get the address Value.
>>
>> I figured GetOperand was a good starting point, and could support most
>> of the operand use cases out there.
>
>
> I'm not sure if I understand. The load instruction takes an address as
> an argument and stores the value into a register, therefore you must
> already have the address already. Or am I misinterpreting what you're
> saying?

When I parse an expression, it gets turned into a Value and stored
away for further processing.  (Actually, it gets turned into calls
into LLVM for creating that Value object when the function generator
is run, but anyway...)  At that point, I don't keep separate track of
what went into the Value... I can examine the Value itself to get that
information, or do without it.

Any value that lives in memory is represented by a LoadInst from a
pointer to that memory.  To take the address, I get the pointer back
out of the LoadInst.  Anything that isn't a LoadInst cannot have its
address taken.  I end up with about the same rules that C and C++ have
for when an address can be taken.

>
>
>> When I've parsed an int literal and put it on my evaluation stack as a
>> Value, there's a case where I need to get it back as an int.
>> Specifically, the LLVMBuildExtractValue function requires an int, not
>> a Constant, to represent the member. ?I believe that GEP does as well
>> when applied to a struct.
>
>
> GEP doesn't need to take a constant to work.
>
> %0 = alloca { i32, i32 }
> %1 = alloca i32
> store i32 0, %1
> %2 = load %1
> %3 = getelementptr { i32, i32 }*, i32 0, %2
> %4 = load %3
>
> extractvalue should only be used if you're using value arrays or
> structs, and you need to statically know the indexes. If you don't,
> then you really should be using GEPs and let the optimizations do
> their thing.

That works in most cases.  Perhaps it should be that way in all cases.
 I wanted to be able to work with struct values without having to
spill them first.  Not that it would make any real difference in the
optimized code.

>> In order to do away with include files, I'm supporting importing
>> modules in bitcode form. ?To call a function from an imported module,
>> I need to put an external into the compiled module, and it really
>> ought to have the same function and argument attributes as the
>> original. ?And I want to be able to do that while JITting at runtime
>> as well.
>
>
> If I understand correctly, why aren't the functions already marked
> external? If they aren't then an optimizer could theoretically
> optimize them away. It may also be more appropriate to pass the
> function information through some different channel by the frontend,
> rather than directly processing the bytecode. Anyone else have any
> experience with doing this?

The functions are marked external in the imported module.  But I must
create a matching declaration in the module I'm compiling in order to
create calls to them.

Functions that are not marked external are not imported.

Also, functions in the imported module can be JITted and called at
compile time.  Public function/type generators would be used
extensively this way, and would let you ship the equivalent of
template functions/classes in compiled form, something you *still*
can't do with most existing C++ compilers.

Anyway, consider the patch withdrawn (except for that one bit you
already committed).  Thank you for looking at it and telling me more
about the motivation behind the C-binding's current state.


From kennethuil at gmail.com  Fri Oct  9 20:21:18 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Fri, 9 Oct 2009 20:21:18 -0500
Subject: [LLVMdev] Is ExecutionEngine always meant to be a singleton?
In-Reply-To: <8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
References: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com>
	<8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
Message-ID: <400d33ea0910091821j6390b466mf3366bfc3c6511d2@mail.gmail.com>

On Fri, Oct 9, 2009 at 5:30 PM, Eric Christopher <echristo at apple.com> wrote:
>
>> If it's supposed to always be a singleton, should there be a way to
>> get the process's ExecutionEngine instance?
>>
>
> I can't see why. You could make a server to process llvm code.

Do you mean create a separate server process to which you send llvm
code and receive back native machine code?

The reason why it would make sense to expose the process's singleton
ExecutionEngine instance is the same as the reason for exposing any
other singleton: to make it easier for a client to use it properly.
The way it is now, if you have two different modules that want to use
the ExecutionEngine, you have to arrange for one to create it and the
other to get it passed in, or for each to check a common global
variable that they're both linked to before trying to create it.  This
tends to couple the modules more tightly together than you might want,
and throws a big wrench into any effort to mix-and-match modules
(especially modules that you didn't write) that might have a use for
the ExecutionEngine.  To say nothing of the case where one module
*creates* the other one, and they both want to use the
ExecutionEngine.... and also allow the created module to use it later
after it's been llc'd.

Exposing it as a singleton allows all of these use cases, and many
others that I haven't thought of, to work cleanly.  And it makes it
more obvious how to implement the more usual use cases.  And it makes
explicit the fact that only a single ExecutionEngine is allowed to
exist.

From jyasskin at google.com  Fri Oct  9 20:27:24 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Fri, 9 Oct 2009 18:27:24 -0700
Subject: [LLVMdev] Is ExecutionEngine always meant to be a singleton?
In-Reply-To: <8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
References: <400d33ea0910080919t66c6c470xc55fb328a9b2d02e@mail.gmail.com>
	<8BB86CC8-CCAD-4677-A2D7-C695291C5D25@apple.com>
Message-ID: <bb55930e0910091827n65967dd5udd0d4c7651d6bb24@mail.gmail.com>

On Fri, Oct 9, 2009 at 3:30 PM, Eric Christopher <echristo at apple.com> wrote:
>
> On Oct 8, 2009, at 9:19 AM, Kenneth Uildriks wrote:
>
>> Right now, on X86, creating multiple ExecutionEngines in the same
>> process causes an assertion.
>>
>
> Yes. This is by design.

Why? By default, I'd rather get rid of singleton requirements than
expose them to users.

>> If it's supposed to always be a singleton, should there be a way to
>> get the process's ExecutionEngine instance?
>>
>
> I can't see why. You could make a server to process llvm code.
>
>> This would, among other things, allow "lli" to execute bitcode that
>> itself uses the ExecutionEngine.
>
> I think you're doing something a bit fishy here. I'm not sure how
> you're generating code, but you may want to look at Unladen Swallow or
> Rubinius or the Kaleidoscope tutorial for how ExecutionEngine is
> generally used for jitting, and jitting in general.
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From viridia at gmail.com  Fri Oct  9 22:58:29 2009
From: viridia at gmail.com (Talin)
Date: Fri, 09 Oct 2009 20:58:29 -0700
Subject: [LLVMdev] DebugFactory
In-Reply-To: <d1b71f830910071521u20f4050bh421472e98e375162@mail.gmail.com>
References: <4AB87938.6080807@gmail.com>	
	<352a1fb20909220921h7577d473v90c9c61c05de61ca@mail.gmail.com>	
	<352a1fb20909220921w5c61511am5712e49a3a3b6cfa@mail.gmail.com>	
	<d1b71f830909221649l4e2233c1h215d88529ea8ee2c@mail.gmail.com>	
	<58C4E46A-95EC-40E2-9E1F-4E9E09C8B699@apple.com>	
	<d1b71f830909231427r51de6aeek53d4aa78abcd7122@mail.gmail.com>	
	<352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>	
	<d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>	
	<352a1fb20910070950r4fb8acc0r69682c4a20c50226@mail.gmail.com>
	<d1b71f830910071521u20f4050bh421472e98e375162@mail.gmail.com>
Message-ID: <4AD00665.5030104@gmail.com>

The old patch works, it's just that when you pass "0, 0, 0" for size, 
align and offset the compiler can't decide which method to call since 
"0" can be either a pointer or an integer.

I can produce a new patch if you like, but I'm having trouble thinking 
of good names for the new methods. Alternatively, I suppose we could 
re-arrange the order of the parameters slightly to make the overloaded 
methods unambiguous.

I'd like to hear what you think before proceeding any further. I do want 
to get this in, though, as it has been very useful to my work.

Talin wrote:
> OK so the problem is that the compiler sees '0' and can't decide whether its
> an integer or a null pointer of type Constant *. I guess the new functions
> will have to have slightly different names.
>
> On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote:
>
>   
>> On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote:
>>     
>>> Here is a patch that does just that.
>>>       
>> This does not work. I'm getting
>>
>> llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function
>> ?llvm::DIType
>> clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType,
>> llvm::DICompileUnit)?:
>> /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225:
>> error: call of overloaded ?CreateDerivedType(unsigned int&,
>> llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int,
>> int, int, int, llvm::DIType&)? is ambiguous
>> llvm/include/llvm/Analysis/DebugInfo.h:530: note: candidates are:
>> llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
>> llvm::DIDescriptor, llvm::StringRef, llvm::DICompileUnit, unsigned
>> int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType)
>> llvm/include/llvm/Analysis/DebugInfo.h:540: note:
>> llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int,
>> llvm::DIDescriptor, const std::string&, llvm::DICompileUnit, unsigned
>> int, llvm::Constant*, llvm::Constant*, llvm::Constant*, unsigned int,
>> llvm::DIType)
>>
>> -
>> Devang
>>
>>     
>
>
>
>   


From kuba at gcc.gnu.org  Sat Oct 10 09:48:50 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Sat, 10 Oct 2009 12:48:50 -0200
Subject: [LLVMdev] PR3707
Message-ID: <F7E2E741-75AD-4CD3-B801-03F162C803B2@gcc.gnu.org>

Hello,

I'm back :) This patch fixes pr3707.

Regards
-Jakub
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr3707.patch
Type: application/octet-stream
Size: 3247 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091010/301a2761/attachment.obj 

From kuba at gcc.gnu.org  Sat Oct 10 10:19:38 2009
From: kuba at gcc.gnu.org (Jakub Staszak)
Date: Sat, 10 Oct 2009 13:19:38 -0200
Subject: [LLVMdev] PR5087
Message-ID: <A54B892B-45F1-4F5F-83F4-D6D61697F760@et.pl>

Hello,

Some time ago I reported bug #5087. I also added proposed patch. Can  
anyone look at this?

Regards
-Jakub

From clattner at apple.com  Sat Oct 10 17:14:21 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 10 Oct 2009 15:14:21 -0700
Subject: [LLVMdev] 2.6 release notes
Message-ID: <65A36C84-B33A-49A0-94F0-B333FDA2CF11@apple.com>

Hi All,

I'm done with the first pass over the 2.6 release notes, see them here:
http://llvm.org/docs/ReleaseNotes-2.6.html

Please feel free to directly edit the file or send improvements.  We  
aim to release 2.6 tomorrow or early next week.

-Chris

From clattner at apple.com  Sun Oct 11 15:09:34 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 13:09:34 -0700
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
Message-ID: <AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>


On Oct 6, 2009, at 5:47 PM, Kenneth Uildriks wrote:

> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks  
> <kennethuil at gmail.com> wrote:
>> My front-end is sync'd with the trunk now, and working well, but it
>> required some additional functions exposed in the C bindings.  I
>> hereby submit them for review and approval for inclusion in the  
>> trunk.
>>
>
> LLVMGetAttribute had a bug in it.  Here's the revised version of the  
> patch

Hi Kenneth,

Thanks for working on this.  I have some additional comments:


+/** See the llvm::Use class. */
+typedef struct LLVMOpaqueUse *LLVMUseRef;

My understanding is that this actually conceptually corresponds to  
use_iterator, not Use.  Please name this something like  
LLVMUseIterator.  Also, please document this, not just referring to  
llvm::Use.


+int LLVMHasInitializer(LLVMValueRef GlobalVar);
  LLVMValueRef LLVMGetInitializer(LLVMValueRef GlobalVar);

Isn't LLVMHasInitializer just  LLVMGetInitializer(x) != 0?


Otherwise, looks ok to me,

-Chris

From kennethuil at gmail.com  Sun Oct 11 15:21:52 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 11 Oct 2009 15:21:52 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
Message-ID: <400d33ea0910111321x2a72edcbwe7ca34a7808c9490@mail.gmail.com>

On Sun, Oct 11, 2009 at 3:09 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 6, 2009, at 5:47 PM, Kenneth Uildriks wrote:
>
>> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com>
>> wrote:
>>>
>>> My front-end is sync'd with the trunk now, and working well, but it
>>> required some additional functions exposed in the C bindings. ?I
>>> hereby submit them for review and approval for inclusion in the trunk.
>>>
>>
>> LLVMGetAttribute had a bug in it. ?Here's the revised version of the patch
>
> Hi Kenneth,
>
> Thanks for working on this. ?I have some additional comments:
>
>
> +/** See the llvm::Use class. */
> +typedef struct LLVMOpaqueUse *LLVMUseRef;
>
> My understanding is that this actually conceptually corresponds to
> use_iterator, not Use. ?Please name this something like LLVMUseIterator.
> ?Also, please document this, not just referring to llvm::Use.

I was following the pattern of Functions, Globals, etc., where you get
a Use* (not a use_iterator), and then pass it back to a GetNextUse
call, which turns it back into an iterator and advances it.

>
>
> +int LLVMHasInitializer(LLVMValueRef GlobalVar);
> ?LLVMValueRef LLVMGetInitializer(LLVMValueRef GlobalVar);
>
> Isn't LLVMHasInitializer just ?LLVMGetInitializer(x) != 0?
>
>
> Otherwise, looks ok to me,
>
> -Chris
>

So you want the whole patch, or just the pieces you highlighted?


From kennethuil at gmail.com  Sun Oct 11 15:25:36 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 11 Oct 2009 15:25:36 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
Message-ID: <400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>

On Sun, Oct 11, 2009 at 3:09 PM, Chris Lattner <clattner at apple.com> wrote:
>
> Isn't LLVMHasInitializer just ?LLVMGetInitializer(x) != 0?

Last time I tried that, LLVMGetInitializer threw an assertion when the
global variable didn't actually have one.  Has this changed?


From pijnacker at dse.nl  Sun Oct 11 15:34:35 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Sun, 11 Oct 2009 22:34:35 +0200
Subject: [LLVMdev] Problems linking shared library with __declspec(dllexport)
Message-ID: <20091011203435.GA22484@asus>

Hi all,

I am trying to use llvm-gcc to link shared libraries on windows/mingw32.
When I try to link libraries that contain functions declared with
  __declspec(dllexport) someFunction();

I get the link error:

  Cannot export _someFunction: symbol not found

Removing the declspec directive solves the problem, but this is not a 
very feasible solution for me.
Using 'regular' gcc does not have this problem.

Should I consider this a bug?

Thanks,

Ronald

From clattner at apple.com  Sun Oct 11 15:35:27 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 13:35:27 -0700
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
	<400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>
Message-ID: <ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>


On Oct 11, 2009, at 1:25 PM, Kenneth Uildriks wrote:

> On Sun, Oct 11, 2009 at 3:09 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>>
>> Isn't LLVMHasInitializer just  LLVMGetInitializer(x) != 0?
>
> Last time I tried that, LLVMGetInitializer threw an assertion when the
> global variable didn't actually have one.  Has this changed?

No idea.  It would be more C like to return null.  The C  
implementation of the function can check and return null if not set.

> I was following the pattern of Functions, Globals, etc., where you get
> a Use* (not a use_iterator), and then pass it back to a GetNextUse
> call, which turns it back into an iterator and advances it.

Conceptually you're returning an iterator.  It happens to be  
implemented as a tight wrapper around the Use.
>
> So you want the whole patch, or just the pieces you highlighted?

Please resend an updated patch (the whole thing)

-Chris

From kennethuil at gmail.com  Sun Oct 11 15:38:58 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 11 Oct 2009 15:38:58 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
	<400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>
	<ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>
Message-ID: <400d33ea0910111338r5bf576e4x24cc62d9e5d8c267@mail.gmail.com>

On Sun, Oct 11, 2009 at 3:35 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 11, 2009, at 1:25 PM, Kenneth Uildriks wrote:
>
>> On Sun, Oct 11, 2009 at 3:09 PM, Chris Lattner <clattner at apple.com> wrote:
>>>
>>> Isn't LLVMHasInitializer just ?LLVMGetInitializer(x) != 0?
>>
>> Last time I tried that, LLVMGetInitializer threw an assertion when the
>> global variable didn't actually have one. ?Has this changed?
>
> No idea. ?It would be more C like to return null. ?The C implementation of
> the function can check and return null if not set.
>
>> I was following the pattern of Functions, Globals, etc., where you get
>> a Use* (not a use_iterator), and then pass it back to a GetNextUse
>> call, which turns it back into an iterator and advances it.
>
> Conceptually you're returning an iterator. ?It happens to be implemented as
> a tight wrapper around the Use.
>>
>> So you want the whole patch, or just the pieces you highlighted?
>
> Please resend an updated patch (the whole thing)
>
> -Chris
>

All right.  You should see it by tonight.


From anton at korobeynikov.info  Sun Oct 11 16:21:34 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 12 Oct 2009 01:21:34 +0400
Subject: [LLVMdev] Problems linking shared library with
	__declspec(dllexport)
In-Reply-To: <20091011203435.GA22484@asus>
References: <20091011203435.GA22484@asus>
Message-ID: <b087fca00910111421p17cdab8al891b7da6f0b89b69@mail.gmail.com>

> I am trying to use llvm-gcc to link shared libraries on windows/mingw32.
> When I try to link libraries that contain functions declared with
> ?__declspec(dllexport) someFunction();
>
> I get the link error:
>
> ?Cannot export _someFunction: symbol not found
dllexport declspec should be put on the function definition, in this
example there is nothing to export - dllexport without function body
is meaningless.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From ofv at wanadoo.es  Sun Oct 11 16:42:50 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Sun, 11 Oct 2009 23:42:50 +0200
Subject: [LLVMdev] Problems linking shared library with
	__declspec(dllexport)
References: <20091011203435.GA22484@asus>
	<b087fca00910111421p17cdab8al891b7da6f0b89b69@mail.gmail.com>
Message-ID: <87ocodmwth.fsf@telefonica.net>

Anton Korobeynikov <anton at korobeynikov.info> writes:

>> I am trying to use llvm-gcc to link shared libraries on windows/mingw32.
>> When I try to link libraries that contain functions declared with
>> ?__declspec(dllexport) someFunction();
>>
>> I get the link error:
>>
>> ?Cannot export _someFunction: symbol not found
> dllexport declspec should be put on the function definition, in this
> example there is nothing to export - dllexport without function body
> is meaningless.

This is not correct.

The compiler remembers the dllexport declspec and when it finds the
definition, it applies it.

It works on MSVC++ and MinGW's gcc.

-- 
?scar


From atomicdog.jwm at gmail.com  Sun Oct 11 17:15:35 2009
From: atomicdog.jwm at gmail.com (John Myers)
Date: Sun, 11 Oct 2009 15:15:35 -0700
Subject: [LLVMdev] 2.6 release notes
Message-ID: <91226b40910111515p7e9d23dk1e01c3c2ea1c5e20@mail.gmail.com>

The PIC16 is an 8-bit target but under the "LLVM IR and Core
Improvements"heading it's called a 16-bit target.

--John


> ---------- Forwarded message ----------
> From: Chris Lattner <clattner at apple.com>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Date: Sat, 10 Oct 2009 15:14:21 -0700
> Subject: [LLVMdev] 2.6 release notes
> Hi All,
>
> I'm done with the first pass over the 2.6 release notes, see them here:
> http://llvm.org/docs/Relea
>
> On Sun, Oct 11, 2009 at 10:00 AM, <llvmdev-request at cs.uiuc.edu> wrote:
>
> You can reach the person managing the list at
>         <http://llvm.org/docs/ReleaseNotes-2.6.html>
> 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. 2.6 release notes (Chris Lattner)seNotes-2.6.html<http://llvm.org/docs/ReleaseNotes-2.6.html>
>
> Please feel free to directly edit the file or send improvements.  We aim to
> release 2.6 tomorrow or early next week.
>
> -Chris
>
>
> _______________________________________________
> LLVMdev mailing list
> LLVMdev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091011/624aec4b/attachment.html 

From kennethuil at gmail.com  Sun Oct 11 17:50:47 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Sun, 11 Oct 2009 17:50:47 -0500
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
	<400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>
	<ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>
Message-ID: <400d33ea0910111550t66df1a43j4d1ba7886c6594b8@mail.gmail.com>

On Sun, Oct 11, 2009 at 3:35 PM, Chris Lattner <clattner at apple.com> wrote:
>
> Please resend an updated patch (the whole thing)

Here it is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbindings.patch
Type: text/x-patch
Size: 8856 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091011/4d96baa3/attachment.bin 

From clattner at apple.com  Sun Oct 11 18:20:01 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 16:20:01 -0700
Subject: [LLVMdev] 2.6 release notes
In-Reply-To: <91226b40910111515p7e9d23dk1e01c3c2ea1c5e20@mail.gmail.com>
References: <91226b40910111515p7e9d23dk1e01c3c2ea1c5e20@mail.gmail.com>
Message-ID: <E8AC55C6-D924-4B4A-A87F-233369CD1FD6@apple.com>

On Oct 11, 2009, at 3:15 PM, John Myers wrote:
> The PIC16 is an 8-bit target but under the "LLVM IR and Core  
> Improvements" heading it's called a 16-bit target.

I think it uses 16-bit pointers though, right?  I clarified in r83815.

Thanks!

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091011/45593d98/attachment.html 

From atomicdog.jwm at gmail.com  Sun Oct 11 18:50:52 2009
From: atomicdog.jwm at gmail.com (John Myers)
Date: Sun, 11 Oct 2009 16:50:52 -0700
Subject: [LLVMdev] 2.6 release notes
In-Reply-To: <E8AC55C6-D924-4B4A-A87F-233369CD1FD6@apple.com>
References: <91226b40910111515p7e9d23dk1e01c3c2ea1c5e20@mail.gmail.com>
	<E8AC55C6-D924-4B4A-A87F-233369CD1FD6@apple.com>
Message-ID: <91226b40910111650u655819e7i867539b4ed33773e@mail.gmail.com>

I'm not sure about the pointer size since I haven't looked at the PIC16 port
that closely (I assume/hope it would be otherwise it would be really
inefficient using something larger).

On Sun, Oct 11, 2009 at 4:20 PM, Chris Lattner <clattner at apple.com> wrote:

> On Oct 11, 2009, at 3:15 PM, John Myers wrote:
>
> The PIC16 is an 8-bit target but under the "LLVM IR and Core Improvements"heading it's called a 16-bit target.
>
>
> I think it uses 16-bit pointers though, right?  I clarified in r83815.
>
> Thanks!
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091011/f2b01d37/attachment.html 

From solusstultus at gmail.com  Sun Oct 11 19:29:37 2009
From: solusstultus at gmail.com (Gregory Diamos)
Date: Sun, 11 Oct 2009 17:29:37 -0700 (PDT)
Subject: [LLVMdev] Re presenting SIMT programs in LLVM
Message-ID: <25849156.post@talk.nabble.com>


I would like to start by thanking every developer who has contributed to LLVM
for releasing such a high quality project.  It has been incredibly valuable
to several projects that I have worked on.

My name is Gregory Diamos, I am a PhD student at Georgia Tech working on
Ocelot (http://code.google.com/p/gpuocelot/).  Ocelot is a dynamic binary
translator from PTX (a virtual instruction set used by NVIDIA GPUs) to
multi-core x86.  We currently use LLVM's JIT as our x86 code generator.  We
have a prototype implementation finished that can execute most CUDA
applications on our google code page using LLVM as a backend.

Most of the program transformations currently available in LLVM are equally
applicable to PTX programs as well as single threaded programs since the PTX
instruction set closely resembles LLVM.  However, PTX explicitly deals with
single-instruction multiple-thread (SIMT) programs where many hundreds or
thousands of threads cooperatively execute a program.  All threads begin
executing the same program and then can take different paths depending on
input data.  During execution, threads may synchronize via barriers, votes,
and atomic operations which are made visible in the instruction set. 
Furthermore, the number and synchronziation domains of threads are
explicitly declared before a program is executed.

When expressing PTX programs in LLVM, we run into several problems, most
significantly the handling of synchronization instructions (barriers).  In
order to correctly handle barriers with low overhead (ie without using
locks), we have to significantly change the control flow structure of a
program, which has implications on the types and quality of optimizations
that can be performed on translated programs.  For example, we do not
currently have the ability to use LLVM passes to move invariant code around
barriers or fuse threads together than can be proved to always take the same
path through the control flow graph between barriers.

We could, and are planning to, implement these optimizations on our end
before we translate from PTX to LLVM, but I thought that I would ask here to
see if there was anything similar that was being done within the LLVM
project.  A way of representing a synchronization operation in LLVM (a
barrier across all threads) and a way of exposing the number of threads
executing the program to the optimization passes would be particularly
useful.

I have heard that several industry compilers are planning to use LLVM as an
IR for OpenCL backend compilers and it seems like these same problems will
show up again when those projects become more mature.  It might make sense
to at least start thinking about them now.

Cheers

Greg D
-- 
View this message in context: http://www.nabble.com/Representing-SIMT-programs-in-LLVM-tp25849156p25849156.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.


From davidterei at gmail.com  Sun Oct 11 20:13:57 2009
From: davidterei at gmail.com (David Terei)
Date: Mon, 12 Oct 2009 12:13:57 +1100
Subject: [LLVMdev] 2.6 release notes
In-Reply-To: <65A36C84-B33A-49A0-94F0-B333FDA2CF11@apple.com>
References: <65A36C84-B33A-49A0-94F0-B333FDA2CF11@apple.com>
Message-ID: <150b8f420910111813h656d80e3y502e494542d76b50@mail.gmail.com>

What is the reason for the splitting of add and others into integer
and floating point versions? Consistency with the div and remainder
operations? I think the reason should be made clear in the release
notes.

Cheers,
David

2009/10/11 Chris Lattner <clattner at apple.com>:
> Hi All,
>
> I'm done with the first pass over the 2.6 release notes, see them here:
> http://llvm.org/docs/ReleaseNotes-2.6.html
>
> Please feel free to directly edit the file or send improvements. ?We
> aim to release 2.6 tomorrow or early next week.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From clattner at apple.com  Sun Oct 11 20:18:22 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 18:18:22 -0700
Subject: [LLVMdev] 2.6 release notes
In-Reply-To: <150b8f420910111813h656d80e3y502e494542d76b50@mail.gmail.com>
References: <65A36C84-B33A-49A0-94F0-B333FDA2CF11@apple.com>
	<150b8f420910111813h656d80e3y502e494542d76b50@mail.gmail.com>
Message-ID: <029D0391-ABAC-4A23-A698-7C6ECAF34402@apple.com>


On Oct 11, 2009, at 6:13 PM, David Terei wrote:

> What is the reason for the splitting of add and others into integer
> and floating point versions? Consistency with the div and remainder
> operations? I think the reason should be made clear in the release
> notes.

There are flags that only make sense for integer ops that don't make  
sense for float ops.  Those flags are listed.

-Chris

>
> Cheers,
> David
>
> 2009/10/11 Chris Lattner <clattner at apple.com>:
>> Hi All,
>>
>> I'm done with the first pass over the 2.6 release notes, see them  
>> here:
>> http://llvm.org/docs/ReleaseNotes-2.6.html
>>
>> Please feel free to directly edit the file or send improvements.  We
>> aim to release 2.6 tomorrow or early next week.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>


From clattner at apple.com  Sun Oct 11 23:01:17 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 21:01:17 -0700
Subject: [LLVMdev] Some additions to the C bindings
In-Reply-To: <400d33ea0910111550t66df1a43j4d1ba7886c6594b8@mail.gmail.com>
References: <400d33ea0910061213g15c5b4c6ga8fe4f09b3470ec@mail.gmail.com>
	<400d33ea0910061747o66dcb2c4r9d8ccafd773e338a@mail.gmail.com>
	<AFA57BD3-8B0F-4AF3-86F3-B14796434CB9@apple.com>
	<400d33ea0910111325h1745ffe3qf18e5c3ef1c88b9c@mail.gmail.com>
	<ECA631AB-4F18-4797-98CE-841E7A300C23@apple.com>
	<400d33ea0910111550t66df1a43j4d1ba7886c6594b8@mail.gmail.com>
Message-ID: <CC905174-F6F6-43DE-82B7-804975D0B268@apple.com>

thanks, applied in r83821

On Oct 11, 2009, at 3:50 PM, Kenneth Uildriks wrote:

> On Sun, Oct 11, 2009 at 3:35 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>>
>> Please resend an updated patch (the whole thing)
>
> Here it is.
> <cbindings.patch>


From clattner at apple.com  Sun Oct 11 23:23:13 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 21:23:13 -0700
Subject: [LLVMdev] PR5087
In-Reply-To: <A54B892B-45F1-4F5F-83F4-D6D61697F760@et.pl>
References: <A54B892B-45F1-4F5F-83F4-D6D61697F760@et.pl>
Message-ID: <706B0EDB-B3A6-412E-9A13-6EF231B44FFB@apple.com>


On Oct 10, 2009, at 8:19 AM, Jakub Staszak wrote:

> Hello,
>
> Some time ago I reported bug #5087. I also added proposed patch. Can
> anyone look at this?

Thanks for pinging this, I didn't see it.  Applied in r83822, please  
close the bug.  Thanks a lot!

-Chris

From clattner at apple.com  Sun Oct 11 23:27:43 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 11 Oct 2009 21:27:43 -0700
Subject: [LLVMdev] PR3707
In-Reply-To: <F7E2E741-75AD-4CD3-B801-03F162C803B2@gcc.gnu.org>
References: <F7E2E741-75AD-4CD3-B801-03F162C803B2@gcc.gnu.org>
Message-ID: <B9BE90E2-C04E-49F5-801F-71818FF9C055@apple.com>

On Oct 10, 2009, at 7:48 AM, Jakub Staszak wrote:

> Hello,
>
> I'm back :)

Great!

> This patch fixes pr3707.

Can you explain a little more what this does?  What is the intuition  
behind disabling this optimization?

-Chris

From pijnacker at dse.nl  Mon Oct 12 01:47:54 2009
From: pijnacker at dse.nl (Ronald Pijnacker)
Date: Mon, 12 Oct 2009 08:47:54 +0200
Subject: [LLVMdev] Problems linking shared library
	with	__declspec(dllexport)
In-Reply-To: <b087fca00910111421p17cdab8al891b7da6f0b89b69@mail.gmail.com>
References: <20091011203435.GA22484@asus>
	<b087fca00910111421p17cdab8al891b7da6f0b89b69@mail.gmail.com>
Message-ID: <20091012064754.GA24312@asus>

> > I am trying to use llvm-gcc to link shared libraries on windows/mingw32.
> > When I try to link libraries that contain functions declared with
> > ?__declspec(dllexport) someFunction();
> >
> > I get the link error:
> >
> > ?Cannot export _someFunction: symbol not found
> dllexport declspec should be put on the function definition, in this
> example there is nothing to export - dllexport without function body
> is meaningless.

Ok, you're right.
The declaration is actually there in the function definition.
Sorry to provide a broken example.
Here is a more acurate one:

--- function.c
  __declspec(dllexport) someFunction()
  {
      printf("Hi\n");
  }
---

Compiling this gives:

  $ llvm-gcc -shared -o libfunction.dll function.c
  Cannot export _someFunction: symbol not found
  collect2: ld returned 1 exit status

Thanks,

Ronald

From anton at korobeynikov.info  Mon Oct 12 03:35:23 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 12 Oct 2009 12:35:23 +0400
Subject: [LLVMdev] Problems linking shared library with
	__declspec(dllexport)
In-Reply-To: <20091012064754.GA24312@asus>
References: <20091011203435.GA22484@asus>
	<b087fca00910111421p17cdab8al891b7da6f0b89b69@mail.gmail.com>
	<20091012064754.GA24312@asus>
Message-ID: <b087fca00910120135x1be1982x134a98a3b917e3ee@mail.gmail.com>

>  $ llvm-gcc -shared -o libfunction.dll function.c
>  Cannot export _someFunction: symbol not found
>  collect2: ld returned 1 exit status
Right, this is a bug introduced recently - we need to emit linker
directive with unmangled, but decorated name...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From cprasenj at in.ibm.com  Mon Oct 12 05:46:27 2009
From: cprasenj at in.ibm.com (Prasenjit Chakraborty)
Date: Mon, 12 Oct 2009 16:16:27 +0530
Subject: [LLVMdev] Accessing Loop Variables
Message-ID: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>


Hi,
      How do I access the loop variables in a loop.

for(i = 0; i < N; i++)
      for(j = 0; j < M; j++)
            A[i][j+k] = i + j;

Is there anyway for me to know that in A[i][j+k], i & j are loop variables
whereas k is not!

Regards,

Prasenjit Chakraborty
Performance Modeling and Analysis
IBM Systems & Technology Lab


From timo.lindfors at iki.fi  Mon Oct 12 08:02:36 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Mon, 12 Oct 2009 16:02:36 +0300
Subject: [LLVMdev] [PATCH] docs/Bugpoint.html: mention -debug-pass=Arguments
Message-ID: <84iqekbw9f.fsf@sauna.l.org>

A non-text attachment was scrubbed...
Name: llvm-doc-bugpoint-debug-arguments1.patch
Type: text/x-diff
Size: 775 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/216bb8da/attachment.bin 

From timo.lindfors at iki.fi  Mon Oct 12 08:31:20 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Mon, 12 Oct 2009 16:31:20 +0300
Subject: [LLVMdev] [PATCH] docs/WritingAnLLVMPass.html:
	s/heirarchy/hierarchy/
Message-ID: <84eip8buxj.fsf@sauna.l.org>

A non-text attachment was scrubbed...
Name: llvm-docs-writing-pass-typo1.patch
Type: text/x-diff
Size: 407 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/27de943d/attachment.bin 

From edwintorok at gmail.com  Mon Oct 12 08:37:56 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Mon, 12 Oct 2009 16:37:56 +0300
Subject: [LLVMdev] [PATCH] docs/WritingAnLLVMPass.html:
	s/heirarchy/hierarchy/
In-Reply-To: <84eip8buxj.fsf@sauna.l.org>
References: <84eip8buxj.fsf@sauna.l.org>
Message-ID: <4AD33134.2020407@gmail.com>

On 2009-10-12 16:31, Timo Juhani Lindfors wrote:
> Hi,
>
> attached patch fixes an obvious typo in docs/WritingAnLLVMPass.html.
>   

Applied in r83848, also fixed a similar typo in ProgrammersManual.html

Best regards,
--Edwin

From timo.lindfors at iki.fi  Mon Oct 12 08:52:26 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Mon, 12 Oct 2009 16:52:26 +0300
Subject: [LLVMdev] current state of building analysis passes out-of-tree
	with llvm-config?
Message-ID: <848wfgbtyd.fsf@sauna.l.org>

Hi,

what's the current state of being able to build simple analysis passes
out-of-tree against only llvm headers and libraries with llvm-config?

I see that clang and klee do not use llvm-config but for example
rubinius does. Should both approaches be documented?

Currently for example docs/WritingAnLLVMPass.html says

   "you need to create a new directory somewhere in the LLVM source
    base."

while people who only want to experiment with simple passes might feel
more comfortable if they didn't need to create directories inside llvm
source tree. I ended up with the following Makefile:

all:
        g++ -c -o LLVMHello.o `llvm-config --cxxflags` Hello.cpp
        gcc -shared -Wl,-soname,LLVMHello.so -o LLVMHello.so LLVMHello.o

clean:
        rm -f LLVMHello.so LLVMHello.o

(I can not use Makefile.common since it is not installed by 'make
install')

best regards,
Timo Lindfors

From criswell at cs.uiuc.edu  Mon Oct 12 09:27:53 2009
From: criswell at cs.uiuc.edu (John Criswell)
Date: Mon, 12 Oct 2009 09:27:53 -0500
Subject: [LLVMdev] current state of building analysis passes out-of-tree
 with llvm-config?
In-Reply-To: <848wfgbtyd.fsf@sauna.l.org>
References: <848wfgbtyd.fsf@sauna.l.org>
Message-ID: <4AD33CE9.3080205@cs.uiuc.edu>

Timo Juhani Lindfors wrote:
> Hi,
>
> what's the current state of being able to build simple analysis passes
> out-of-tree against only llvm headers and libraries with llvm-config?
>   
Have you considered using the LLVM Project templates (documented at
http://llvm.org/docs/Projects.html)?  This is the build system we use
for Automatic Pool Allocation.  It allows us to reuse all the Makefile
machinery within LLVM; we use Makefiles that are nearly identical to
those used in LLVM, and things "just work" (more or less).  I believe it
automatically uses llvm-config.

Automatic Pool Allocation is available from LLVM's SVN repository
(llvm.org/svn/llvm-project/poolalloc/trunk) if you want an example of a
project that uses this build system.  It currently builds against LLVM
2.6, but the build system is probably still compatible with LLVM mainline.

-- John T.

> I see that clang and klee do not use llvm-config but for example
> rubinius does. Should both approaches be documented?
>
> Currently for example docs/WritingAnLLVMPass.html says
>
>    "you need to create a new directory somewhere in the LLVM source
>     base."
>
> while people who only want to experiment with simple passes might feel
> more comfortable if they didn't need to create directories inside llvm
> source tree. I ended up with the following Makefile:
>
> all:
>         g++ -c -o LLVMHello.o `llvm-config --cxxflags` Hello.cpp
>         gcc -shared -Wl,-soname,LLVMHello.so -o LLVMHello.so LLVMHello.o
>
> clean:
>         rm -f LLVMHello.so LLVMHello.o
>
> (I can not use Makefile.common since it is not installed by 'make
> install')
>
> best regards,
> Timo Lindfors
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   


From pmlopes at gmail.com  Mon Oct 12 09:23:21 2009
From: pmlopes at gmail.com (jetcube)
Date: Mon, 12 Oct 2009 07:23:21 -0700 (PDT)
Subject: [LLVMdev] MIPS backend and VFPU
Message-ID: <994e72e3-c38c-4f28-96c5-07d8a24c96e1@x37g2000yqj.googlegroups.com>

I noticed that the MIPS backend was developed as a backend for the
generic MIPS processor and also as a Google SoC targeting the Allegrex
CPU, however there is no support for vector instructions. I see that
vectorization is a very powerfull weapon from LLVM when compared to
other compilers but in the case of the Allegrex CPU it is not
supported. Are there any plans in the near future to add support for
it?

If not, which CPUs have some kind of VFPU support already implemented
so someone totally noob into the LLVM tablegen could try to look to
add it?

From choudharydhruv at gmail.com  Mon Oct 12 10:08:58 2009
From: choudharydhruv at gmail.com (dhruv choudhary)
Date: Mon, 12 Oct 2009 11:08:58 -0400
Subject: [LLVMdev] Accessing Loop Variables
In-Reply-To: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>
References: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>
Message-ID: <aceb74670910120808l605c3c15o4ea935d2591b19a0@mail.gmail.com>

Hi,

You can use the getInductionVariable() on each loop,and maintain a smallvect
of all induction variables that you have come across.
Also remember to run some passes to hoist loop independent entities out of
the loop.

Cheers

Dhruv

On Mon, Oct 12, 2009 at 6:46 AM, Prasenjit Chakraborty
<cprasenj at in.ibm.com>wrote:

>
> Hi,
>      How do I access the loop variables in a loop.
>
> for(i = 0; i < N; i++)
>      for(j = 0; j < M; j++)
>            A[i][j+k] = i + j;
>
> Is there anyway for me to know that in A[i][j+k], i & j are loop variables
> whereas k is not!
>
> Regards,
>
> Prasenjit Chakraborty
> Performance Modeling and Analysis
> IBM Systems & Technology Lab
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
School of Electrical and Computer Engineering
Georgia Institute of Technology

(M)  +1 770 827 9264
Personal Email : choudharydhruv at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/ad01c59a/attachment.html 

From juanc.martinez.santos at gmail.com  Mon Oct 12 11:59:53 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Mon, 12 Oct 2009 12:59:53 -0400
Subject: [LLVMdev] Options in OPT
Message-ID: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>

Hello,

There is an option that I don't know how to used it.

 *-S*
Write output in LLVM intermediate language (instead of bitcode).

The option appears in the documentation, but I try to use it... I get the
next message:

~/test$ opt -analyze hello.ll -o hello.bc -S
opt: Unknown command line argument '-S'.  Try: 'opt --help'

I also try 'opt --help'; but the option is not listed.

I am using wrong the -S option, or there is something else.

Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/ae017216/attachment.html 

From devang.patel at gmail.com  Mon Oct 12 12:32:32 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 12 Oct 2009 10:32:32 -0700
Subject: [LLVMdev] DebugFactory
In-Reply-To: <4AD00665.5030104@gmail.com>
References: <4AB87938.6080807@gmail.com>
	<352a1fb20909220921w5c61511am5712e49a3a3b6cfa@mail.gmail.com>
	<d1b71f830909221649l4e2233c1h215d88529ea8ee2c@mail.gmail.com>
	<58C4E46A-95EC-40E2-9E1F-4E9E09C8B699@apple.com>
	<d1b71f830909231427r51de6aeek53d4aa78abcd7122@mail.gmail.com>
	<352a1fb20909231538q4074fff3jba54a57b342364f0@mail.gmail.com>
	<d1b71f830910012034r56e50bfcm783acc40e7e5712d@mail.gmail.com>
	<352a1fb20910070950r4fb8acc0r69682c4a20c50226@mail.gmail.com>
	<d1b71f830910071521u20f4050bh421472e98e375162@mail.gmail.com>
	<4AD00665.5030104@gmail.com>
Message-ID: <352a1fb20910121032v7ed020d4j1be0c1818127463a@mail.gmail.com>

On Fri, Oct 9, 2009 at 8:58 PM, Talin <viridia at gmail.com> wrote:
> The old patch works, it's just that when you pass "0, 0, 0" for size, align
> and offset the compiler can't decide which method to call since "0" can be
> either a pointer or an integer.
>
> I can produce a new patch if you like, but I'm having trouble thinking of
> good names for the new methods. Alternatively, I suppose we could re-arrange
> the order of the parameters slightly to make the overloaded methods
> unambiguous.
>
> I'd like to hear what you think before proceeding any further. I do want to
> get this in, though, as it has been very useful to my work.
>

How about you pass reference of Constant instead of pointer to Constant ?
-
Devang

From gohman at apple.com  Mon Oct 12 12:43:06 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 12 Oct 2009 10:43:06 -0700
Subject: [LLVMdev] Accessing Loop Variables
In-Reply-To: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>
References: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>
Message-ID: <218F01E6-E7AD-4000-A6D4-18B064BB7CAE@apple.com>


On Oct 12, 2009, at 3:46 AM, Prasenjit Chakraborty wrote:

>
> Hi,
>      How do I access the loop variables in a loop.
>
> for(i = 0; i < N; i++)
>      for(j = 0; j < M; j++)
>            A[i][j+k] = i + j;
>
> Is there anyway for me to know that in A[i][j+k], i & j are loop  
> variables
> whereas k is not!

The ScalarEvolution analysis can help here. If you've already identified
i, j, and k yourself, you can call getSCEV on them and use the
isLoopInvariant and hasComputableLoopEvolution member functions.

ScalarEvolution doesn't yet help in identifying the indices used in
each dimension of a multi-dimensional array reference in the way that a
traditional dependence analysis would want to see them, though that's
a future goal.

Dan


From timo.lindfors at iki.fi  Mon Oct 12 12:55:39 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Mon, 12 Oct 2009 20:55:39 +0300
Subject: [LLVMdev] Options in OPT
In-Reply-To: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>
	(Juan Carlos Martinez Santos's message of "Mon, 12 Oct 2009 12:59:53
	-0400")
References: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>
Message-ID: <844oq4bip0.fsf@sauna.l.org>

Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com> writes:
> ~/test$ opt -analyze hello.ll -o hello.bc -S
> opt: Unknown command line argument '-S'.  Try: 'opt --help'

Works for me:

$ opt -analyze hello.ll -o hello.bc -S
$ file hello.*
hello.bc: empty
hello.ll: ASCII text

Maybe you have too old opt?

> I also try 'opt --help'; but the option is not listed.

Try opt --help-hidden.


From clattner at apple.com  Mon Oct 12 13:13:02 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 11:13:02 -0700
Subject: [LLVMdev] [PATCH] docs/Bugpoint.html: mention
	-debug-pass=Arguments
In-Reply-To: <84iqekbw9f.fsf@sauna.l.org>
References: <84iqekbw9f.fsf@sauna.l.org>
Message-ID: <766063D4-BC73-4F47-91DA-D1ED881CE3B3@apple.com>


On Oct 12, 2009, at 6:02 AM, Timo Juhani Lindfors wrote:

> Hi,
>
> when reporting
>
> http://llvm.org/bugs/show_bug.cgi?id=5104
>
> I spent quite a while trying to figure out what passes are used by
> "-O1" so that I could give this list to bugpoint. It turns out
> -debug-pass=Arguments is mentioned in docs/HowToSubmitABug.html but
> under a chapter titled "Compile-time optimization bugs" which I
> naively ignored since my bug was not a compile-time bug.
>
> How about mentioning this more explicitely in the bugpoint
> documentation along the lines of the attached patch?

Looks great, applied in r83865, thanks!

-Chris

From samuraileumas at yahoo.com  Mon Oct 12 13:13:23 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Mon, 12 Oct 2009 11:13:23 -0700 (PDT)
Subject: [LLVMdev] Options in OPT
In-Reply-To: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>
References: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>
Message-ID: <989109.69102.qm@web62002.mail.re1.yahoo.com>

Hi Juan Carlos,

It looks to me like you're trying to read in LLVM Assembly and output bitcode.  That is the opposite of what -S is supposed to be for.  I'm not sure why it isn't recoginizing the -S option but it looks like there's more wrong than what you're reporting.

--Sam


>
>From: Juan Carlos Martinez Santos <juanc.martinez.santos at gmail.com>
>To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>Sent: Mon, October 12, 2009 11:59:53 AM
>Subject: [LLVMdev] Options in OPT
>
>
>Hello,
> 
>There is an option that I don't know how to used it.
> 
>-S
>
>Write output in LLVM intermediate language (instead of bitcode). 
>
> 
>The option appears in the documentation, but I try to use it... I get the next message:
> 
>~/test$ opt -analyze hello.ll -o hello.bc -S
>opt: Unknown command line argument '-S'.  Try: 'opt --help'
> 
>I also try 'opt --help'; but the option is not listed.
> 
>I am using wrong the -S option, or there is something else.
> 
>Thanks in advance,
>
>-- 
>Juan Carlos
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/58908b25/attachment.html 

From cprasenj at in.ibm.com  Mon Oct 12 13:40:10 2009
From: cprasenj at in.ibm.com (Prasenjit Chakraborty)
Date: Tue, 13 Oct 2009 00:10:10 +0530
Subject: [LLVMdev] Accessing Loop Variables
In-Reply-To: <218F01E6-E7AD-4000-A6D4-18B064BB7CAE@apple.com>
References: <OF43A4C72E.37697939-ON6525764D.003AF09B-6525764D.003B660B@in.ibm.com>
	<218F01E6-E7AD-4000-A6D4-18B064BB7CAE@apple.com>
Message-ID: <OF5243AFB3.B35D8D65-ON6525764D.00665280-6525764D.0066C557@in.ibm.com>

I have not identified i, j or k. The whole point is I want to know that
there are variables i & j which are loop variables.

Calling getInductionVariab;le() returns NULL, reason being I don't see any
PHINode in the loop.

Regards,

Prasenjit Chakraborty
Performance Modeling and Analysis
IBM Systems & Technology Lab


                                                                           
             Dan Gohman                                                    
             <gohman at apple.com                                             
             >                                                          To 
                                       Prasenjit                           
             10/12/2009 11:13          Chakraborty/India/IBM at IBMIN         
             PM                                                         cc 
                                       llvmdev at cs.uiuc.edu                 
                                                                   Subject 
                                       Re: [LLVMdev] Accessing Loop        
                                       Variables                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





On Oct 12, 2009, at 3:46 AM, Prasenjit Chakraborty wrote:

>
> Hi,
>      How do I access the loop variables in a loop.
>
> for(i = 0; i < N; i++)
>      for(j = 0; j < M; j++)
>            A[i][j+k] = i + j;
>
> Is there anyway for me to know that in A[i][j+k], i & j are loop
> variables
> whereas k is not!

The ScalarEvolution analysis can help here. If you've already identified
i, j, and k yourself, you can call getSCEV on them and use the
isLoopInvariant and hasComputableLoopEvolution member functions.

ScalarEvolution doesn't yet help in identifying the indices used in
each dimension of a multi-dimensional array reference in the way that a
traditional dependence analysis would want to see them, though that's
a future goal.

Dan




From devang.patel at gmail.com  Mon Oct 12 13:57:29 2009
From: devang.patel at gmail.com (Devang Patel)
Date: Mon, 12 Oct 2009 11:57:29 -0700
Subject: [LLVMdev] [PATCH] docs/Bugpoint.html: mention
	-debug-pass=Arguments
In-Reply-To: <84iqekbw9f.fsf@sauna.l.org>
References: <84iqekbw9f.fsf@sauna.l.org>
Message-ID: <352a1fb20910121157g2e946879q1b6bb88fd88912ba@mail.gmail.com>

On Mon, Oct 12, 2009 at 6:02 AM, Timo Juhani Lindfors
<timo.lindfors at iki.fi> wrote:
> Hi,
>
> when reporting
>
> http://llvm.org/bugs/show_bug.cgi?id=5104
>
> I spent quite a while trying to figure out what passes are used by
> "-O1" so that I could give this list to bugpoint.

It'd be a good idea if bugpoint supports -O*.
-debug-pass=Arguments won't work in release build.
-
Devang

> It turns out
> -debug-pass=Arguments is mentioned in docs/HowToSubmitABug.html but
> under a chapter titled "Compile-time optimization bugs" which I
> naively ignored since my bug was not a compile-time bug.
>
> How about mentioning this more explicitely in the bugpoint
> documentation along the lines of the attached patch?
>
> best regards,
> Timo Lindfors
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From dag at cray.com  Mon Oct 12 15:07:15 2009
From: dag at cray.com (David Greene)
Date: Mon, 12 Oct 2009 15:07:15 -0500
Subject: [LLVMdev] Alloca Requirements
Message-ID: <200910121507.15755.dag@cray.com>

Are there any implicit assumptions about where alloca instructions
can appear.  I've got a failing test where the only difference 
between a passing test and a failing test is one application of
this code in instcombine:

// Convert: malloc Ty, C - where C is a constant != 1 into: malloc [C x Ty], 1

Seems pretty harmless to me.

Later on the instcombine code does this:

// Scan to the end of the allocation instructions, to skip over a block of
// allocas if possible...

That comment makes me a bit suspicious regarding assumptions about alloca 
placement.

The interesting thing about this testcase is that the extra instcombine makes 
the test pass.  If I omit it, the test fails.  The only differences in the
asm are stack offsets, which leads me to believe that in the failing test 
codegen is not accounting for all allocas properly.

Before this critical instcombine the input code looks like this:

        ; Fails
	%"t$1" = alloca %DV1, align 8		; <%DV1*> [#uses=3]
	%"t$2" = alloca [1 x [1 x <2 x float>]]*, i32 12, align 8		; <[1 x [1 x <2 x 
float>]]**> [#uses=2]
	%tmpcast5 = bitcast [1 x [1 x <2 x float>]]** %"t$2" to %DV2*		; <%DV2*> 
[#uses=2]
	%"t$34" = alloca [9 x [1 x <2 x float>]*], align 8		; <[9 x [1 x <2 x 
float>]*]*> [#uses=3]

Afterward it looks like this:

        ; Passes
	%"t$1" = alloca %DV1, align 8		; <%DV1*> [#uses=3]
	%"t$26" = alloca [12 x [1 x [1 x <2 x float>]]*], align 8		; <[12 x [1 x [1 x 
<2 x float>]]*]*> [#uses=1]
	%"t$26.sub" = getelementptr [12 x [1 x [1 x <2 x float>]]*]* %"t$26", i32 0, 
i32 0		; <[1 x [1 x <2 x float>]]**> [#uses=2]
	%tmpcast5 = bitcast [1 x [1 x <2 x float>]]** %"t$26.sub" to %DV2*		; <%DV2*> 
[#uses=2]
	%"t$34" = alloca [9 x [1 x <2 x float>]*], align 8		; <[9 x [1 x <2 x 
float>]*]*> [#uses=3]

Any thoughts on why this might be a problem?

                                   -Dave

From sricketts at maxentric.com  Mon Oct 12 18:01:05 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Mon, 12 Oct 2009 16:01:05 -0700
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
Message-ID: <6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>

To be more specific, it would be helpful to have some utilities for
finding dependencies (true, output, and anti-). Where is a good place
to start for this kind of analysis?

Thanks,
Scott

On Fri, Oct 9, 2009 at 11:06 AM, Scott Ricketts <sricketts at maxentric.com> wrote:
> I want to be able to detect reduction operations using a method
> similar to that described here:
>
> http://portal.acm.org/citation.cfm?id=237578.237581
>
> (I am open to other suggestions if there is a better technique).
>
> I am curious if anyone has done this with LLVM or if there are and
> recommendations for where to start with my implementation. I am only
> interested in identifying the reductions -- I will not need to do any
> kind of transformation to exploit the parallelism. However, if this
> sort of work might be useful to others, I can try to generalize the
> interface based on any suggestions in case my work gets to the point
> where it could be checked in.
>
> Scott
>

From clattner at apple.com  Mon Oct 12 18:40:05 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 16:40:05 -0700
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
	<6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>
Message-ID: <54972E39-2E89-4B39-86B1-80E14CFF745A@apple.com>


On Oct 12, 2009, at 4:01 PM, Scott Ricketts wrote:

> To be more specific, it would be helpful to have some utilities for
> finding dependencies (true, output, and anti-). Where is a good place
> to start for this kind of analysis?

Hi Scott,

Do you mean loop carried dependencies?  There is some initial work on  
dependence analysis, but it is still pretty young.  We also have  
support for dependence between memory operations that are not loop  
aware.

-Chris

>
> Thanks,
> Scott
>
> On Fri, Oct 9, 2009 at 11:06 AM, Scott Ricketts <sricketts at maxentric.com 
> > wrote:
>> I want to be able to detect reduction operations using a method
>> similar to that described here:
>>
>> http://portal.acm.org/citation.cfm?id=237578.237581
>>
>> (I am open to other suggestions if there is a better technique).
>>
>> I am curious if anyone has done this with LLVM or if there are and
>> recommendations for where to start with my implementation. I am only
>> interested in identifying the reductions -- I will not need to do any
>> kind of transformation to exploit the parallelism. However, if this
>> sort of work might be useful to others, I can try to generalize the
>> interface based on any suggestions in case my work gets to the point
>> where it could be checked in.
>>
>> Scott
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From sricketts at maxentric.com  Mon Oct 12 19:17:41 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Mon, 12 Oct 2009 17:17:41 -0700
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <54972E39-2E89-4B39-86B1-80E14CFF745A@apple.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
	<6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>
	<54972E39-2E89-4B39-86B1-80E14CFF745A@apple.com>
Message-ID: <6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>

> Hi Scott,
>
> Do you mean loop carried dependencies?  There is some initial work on
> dependence analysis, but it is still pretty young.  We also have support for
> dependence between memory operations that are not loop aware.
>
> -Chris

I think the dependence analysis will have to be loop aware. For example:

bb:
        %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next, %bb ]
        %sum = phi i32 [ 0, %bb.nph ], [ %3, %bb ]
        %1 = getelementptr i32* %X, i64 %indvar
        %2 = load i32* %1, align 4
        %3 = add i32 %2, %sum
        %indvar.next = add i64 %indvar, 1
        %exitcond = icmp eq i64 %indvar.next, %tmp.
        br i1 %exitcond, label %bb2, label %bb

I would like to recognize that there is circular dependence (true and
anti-) between %3 and %sum and that the only operations that form this
dependence are associative+commutative (e.g. addition). In this
example, we can see that by just looking at the operands of the %sum
and %3 instructions. But things get more challenging when we toss in,
say, a constant scalar multiply into each iteration. Then the
dependencies have an intermediate operations between them:

bb:
        %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next, %bb ]
        %sum = phi i32 [ 0, %bb.nph ], [ %3, %bb ]
        %1 = getelementptr i32* %X, i64 %indvar
        %2 = load i32* %1, align 4
        %3 = mul i32 %2, 4
%3 = add i32 %2, %sum
        %indvar.next = add i64 %indvar, 1
        %exitcond = icmp eq i64 %indvar.next, %tmp.
        br i1 %exitcond, label %bb2, label %bb

1) %3 has a true dependency on %sum (this is trivial by just looking
at the operands of the add inst)
2) %sum has an anti

From sricketts at maxentric.com  Mon Oct 12 19:23:33 2009
From: sricketts at maxentric.com (Scott Ricketts)
Date: Mon, 12 Oct 2009 17:23:33 -0700
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
	<6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>
	<54972E39-2E89-4B39-86B1-80E14CFF745A@apple.com>
	<6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>
Message-ID: <6d9073030910121723t8a3e697hecdb72b1ee9c478a@mail.gmail.com>

> But things get more challenging when we toss in,
> say, a constant scalar multiply into each iteration. Then the
> dependencies have an intermediate operations between them:
>
> bb:
>        %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next, %bb ]
>        %sum = phi i32 [ 0, %bb.nph ], [ %3, %bb ]
>        %1 = getelementptr i32* %X, i64 %indvar
>        %2 = load i32* %1, align 4
>        %3 = mul i32 %2, 4
> %3 = add i32 %2, %sum
>        %indvar.next = add i64 %indvar, 1
>        %exitcond = icmp eq i64 %indvar.next, %tmp.
>        br i1 %exitcond, label %bb2, label %bb
>
> 1) %3 has a true dependency on %sum (this is trivial by just looking
> at the operands of the add inst)
> 2) %sum has an anti
>

Whoops, ignore the second example.

Anyway, I clearly need to think this through a bit more. But it might
be helpful to start looking at the dependence analysis stuff that is
available. Memory dependence will not help in general I think because
the arithmetic could be all done in intermediate values.

From plmdvy at gmail.com  Mon Oct 12 19:34:15 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Tue, 13 Oct 2009 00:34:15 +0000
Subject: [LLVMdev] haiku comapatability configure regenerated
Message-ID: <9430ad070910121734n139a5687ubf02434e75358927@mail.gmail.com>

This is a patch for the regenerated configure related files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091013/eb1ed755/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haiku.patch
Type: text/x-patch
Size: 11387 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091013/eb1ed755/attachment.bin 

From eocallaghan at auroraux.org  Mon Oct 12 20:03:07 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Tue, 13 Oct 2009 02:03:07 +0100
Subject: [LLVMdev] haiku comapatability configure regenerated
In-Reply-To: <9430ad070910121734n139a5687ubf02434e75358927@mail.gmail.com>
References: <9430ad070910121734n139a5687ubf02434e75358927@mail.gmail.com>
Message-ID: <521640720910121803v703e176cuaa87511ff29effcf@mail.gmail.com>

Commited in rev. 83930.

Many Thanks,
Edward.

2009/10/13 Paul Davey <plmdvy at gmail.com>:
> This is a patch for the regenerated configure related files.
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From Micah.Villmow at amd.com  Mon Oct 12 20:15:25 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Mon, 12 Oct 2009 18:15:25 -0700
Subject: [LLVMdev] 65bit integer math
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>

I have a test case(attached as fc_long.ll) that when run through the
optimizer produces 65bit integer math(fc_long-opt.ll).

 

Now I understand that llvm can have any length integer, but I consider
turning a 64bit mul into multiple 65 bit instructions to be a 'bad'
optimization. This eventually expands to a 128bit multiply
call(__multi3) which I have absolutely no interest in supporting. So I'm
wondering what optimization might be the culprit here so I can disable
it in this situation.

 

Micah

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/e646bec7/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc_long.ll
Type: application/octet-stream
Size: 3302 bytes
Desc: fc_long.ll
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/e646bec7/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc_long-opt.ll
Type: application/octet-stream
Size: 2274 bytes
Desc: fc_long-opt.ll
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/e646bec7/attachment-0001.obj 

From lefever at crhc.illinois.edu  Mon Oct 12 20:17:18 2009
From: lefever at crhc.illinois.edu (Ryan M. Lefever)
Date: Mon, 12 Oct 2009 20:17:18 -0500
Subject: [LLVMdev] hash extras
Message-ID: <4AD3D51E.7070303@crhc.illinois.edu>

I am trying to upgrade my code to use the latest version of llvm from 
svn.  Whenever I include "llvm/ADT/HashExtras.h", I get error messages 
like the following.  Does anyone know what is going on?  Thanks for any 
help.

llvm[1]: Compiling Aux.cpp for Debug build (PIC)
In file included from 
/home/lefever/work/memrep/src/compiler/include/Aux.h:4,
                  from Aux.cpp:1:
/home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:26: 
error: ?hash? is not a template
/home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h: In 
member function ?size_t HASH_NAMESPACE::hash<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > >::operator()(const 
std::string&) const?:
/home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:34: 
error: no match for call to ?(HASH_NAMESPACE::hash<const char*>) (const 
char*)?
/home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:27: 
note: candidates are: size_t HASH_NAMESPACE::hash<T>::operator()(const 
T*) const [with T = const char*]
make[1]: *** 
[/home/lefever/work/memrep/src/compiler/lib/memrep/Debug/Aux.o] Error 1
make[1]: Leaving directory 
`/home/lefever/work/memrep/src/compiler/lib/memrep'
make: *** [compiler/Debug/lib/libmemrep.so] Error 2


From lefever at crhc.illinois.edu  Mon Oct 12 20:40:55 2009
From: lefever at crhc.illinois.edu (Ryan M. Lefever)
Date: Mon, 12 Oct 2009 20:40:55 -0500
Subject: [LLVMdev] hash extras
In-Reply-To: <4AD3D51E.7070303@crhc.illinois.edu>
References: <4AD3D51E.7070303@crhc.illinois.edu>
Message-ID: <4AD3DAA7.4020906@crhc.illinois.edu>

So, after digging around in the old llvm/ADT/hash_map, I think I 
discovered the problem.  Now, if you want to include 
llvm/ADT/HashExtras.h, you have to include the hash_map h file from your 
system (ext/hash_map in my case) and define HASH_NAMESPACE, before you 
include llvm/ADT/HashExtras.  It might be good to include some 
documentation about that for those using HashExtras.

Regards,
Ryan


Ryan M. Lefever wrote:
> I am trying to upgrade my code to use the latest version of llvm from 
> svn.  Whenever I include "llvm/ADT/HashExtras.h", I get error messages 
> like the following.  Does anyone know what is going on?  Thanks for any 
> help.
> 
> llvm[1]: Compiling Aux.cpp for Debug build (PIC)
> In file included from 
> /home/lefever/work/memrep/src/compiler/include/Aux.h:4,
>                   from Aux.cpp:1:
> /home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:26: 
> error: ?hash? is not a template
> /home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h: In 
> member function ?size_t HASH_NAMESPACE::hash<std::basic_string<char, 
> std::char_traits<char>, std::allocator<char> > >::operator()(const 
> std::string&) const?:
> /home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:34: 
> error: no match for call to ?(HASH_NAMESPACE::hash<const char*>) (const 
> char*)?
> /home/lefever/llvm/svn091010/llvm/include/llvm/ADT/HashExtras.h:27: 
> note: candidates are: size_t HASH_NAMESPACE::hash<T>::operator()(const 
> T*) const [with T = const char*]
> make[1]: *** 
> [/home/lefever/work/memrep/src/compiler/lib/memrep/Debug/Aux.o] Error 1
> make[1]: Leaving directory 
> `/home/lefever/work/memrep/src/compiler/lib/memrep'
> make: *** [compiler/Debug/lib/libmemrep.so] Error 2
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From eli.friedman at gmail.com  Mon Oct 12 22:12:27 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 12 Oct 2009 20:12:27 -0700
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <200910121507.15755.dag@cray.com>
References: <200910121507.15755.dag@cray.com>
Message-ID: <f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>

On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote:
> Are there any implicit assumptions about where alloca instructions
> can appear.

Static allocas should appear as a continuous chunk in the entry block,
otherwise other passes might make bad assumptions.

> The interesting thing about this testcase is that the extra instcombine makes
> the test pass. ?If I omit it, the test fails. ?The only differences in the
> asm are stack offsets, which leads me to believe that in the failing test
> codegen is not accounting for all allocas properly.

If running a testcase through -instcombine -instcombine gives a result
that isn't identical to -instcombine, that's a bug.  Please file it if
you have a reduced testcase.

-Eli


From eli.friedman at gmail.com  Mon Oct 12 22:22:00 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 12 Oct 2009 20:22:00 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
Message-ID: <f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>

On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> I have a test case(attached as fc_long.ll) that when run through the
> optimizer produces 65bit integer math(fc_long-opt.ll).
>
>
>
> Now I understand that llvm can have any length integer, but I consider
> turning a 64bit mul into multiple 65 bit instructions to be a ?bad?
> optimization. This eventually expands to a 128bit multiply call(__multi3)
> which I have absolutely no interest in supporting. So I?m wondering what
> optimization might be the culprit here so I can disable it in this
> situation.

I'm pretty sure this is the fault of one of the loop passes (I forget
which one off the top of my head).  It's worth noting that the
optimizer manages to eliminate the loop; computing the exit value of
one of the loop variables uses the wide multiply.

-Eli


From jyasskin at google.com  Mon Oct 12 23:42:43 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Mon, 12 Oct 2009 21:42:43 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
	<f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
Message-ID: <bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>

On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>> I have a test case(attached as fc_long.ll) that when run through the
>> optimizer produces 65bit integer math(fc_long-opt.ll).
>>
>>
>>
>> Now I understand that llvm can have any length integer, but I consider
>> turning a 64bit mul into multiple 65 bit instructions to be a ?bad?
>> optimization. This eventually expands to a 128bit multiply call(__multi3)
>> which I have absolutely no interest in supporting. So I?m wondering what
>> optimization might be the culprit here so I can disable it in this
>> situation.
>
> I'm pretty sure this is the fault of one of the loop passes (I forget
> which one off the top of my head). ?It's worth noting that the
> optimizer manages to eliminate the loop; computing the exit value of
> one of the loop variables uses the wide multiply.

It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your
input and got the attached file. I thought I could add "nuw nsw" to
the arithmetic inside the loop to say that i65 is unnecessary, but
that doesn't cause indvars to leave the arithmetic at i64. Is that a
bug in indvars, or in SCEV, or is this just a natural limitation of
SCEV?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fc_long.ll
Type: application/octet-stream
Size: 1592 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091012/932523ab/attachment-0001.obj 

From eli.friedman at gmail.com  Mon Oct 12 23:48:44 2009
From: eli.friedman at gmail.com (Eli Friedman)
Date: Mon, 12 Oct 2009 21:48:44 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
	<f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
	<bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
Message-ID: <f5aa3e9b0910122148o17bf738ew6d6434f6e0da5df4@mail.gmail.com>

On Mon, Oct 12, 2009 at 9:42 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
>>> I have a test case(attached as fc_long.ll) that when run through the
>>> optimizer produces 65bit integer math(fc_long-opt.ll).
>>>
>>>
>>>
>>> Now I understand that llvm can have any length integer, but I consider
>>> turning a 64bit mul into multiple 65 bit instructions to be a ?bad?
>>> optimization. This eventually expands to a 128bit multiply call(__multi3)
>>> which I have absolutely no interest in supporting. So I?m wondering what
>>> optimization might be the culprit here so I can disable it in this
>>> situation.
>>
>> I'm pretty sure this is the fault of one of the loop passes (I forget
>> which one off the top of my head). ?It's worth noting that the
>> optimizer manages to eliminate the loop; computing the exit value of
>> one of the loop variables uses the wide multiply.
>
> It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your
> input and got the attached file. I thought I could add "nuw nsw" to
> the arithmetic inside the loop to say that i65 is unnecessary, but
> that doesn't cause indvars to leave the arithmetic at i64. Is that a
> bug in indvars, or in SCEV, or is this just a natural limitation of
> SCEV?

It's a limitation of SCEV; the relevant function is
SCEVAddRecExpr::evaluateAtIteration in ScalarEvolution.cpp.

-Eli


From nicholas at mxc.ca  Tue Oct 13 00:18:45 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Mon, 12 Oct 2009 22:18:45 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
Message-ID: <4AD40DB5.60106@mxc.ca>

I haven't looked at your attached .ll, but I have added code to the loop 
analyser to make it do this. Given the choice between not analysing loop 
evolutions and growing arithmetic by an extra bit, it will expand the 
arithmetic. It's in SCEV, which is used by pretty much every loop optimizer.

Nick

Villmow, Micah wrote:
> 
> 
> I have a test case(attached as fc_long.ll) that when run through the 
> optimizer produces 65bit integer math(fc_long-opt.ll).
> 
>  
> 
> Now I understand that llvm can have any length integer, but I consider 
> turning a 64bit mul into multiple 65 bit instructions to be a ?bad? 
> optimization. This eventually expands to a 128bit multiply 
> call(__multi3) which I have absolutely no interest in supporting. So I?m 
> wondering what optimization might be the culprit here so I can disable 
> it in this situation.
> 
>  
> 
> Micah
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From clattner at apple.com  Tue Oct 13 00:33:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 22:33:16 -0700
Subject: [LLVMdev] hash extras
In-Reply-To: <4AD3DAA7.4020906@crhc.illinois.edu>
References: <4AD3D51E.7070303@crhc.illinois.edu>
	<4AD3DAA7.4020906@crhc.illinois.edu>
Message-ID: <24B715A1-3AD5-45EA-A830-F903FA7CC5E6@apple.com>


On Oct 12, 2009, at 6:40 PM, Ryan M. Lefever wrote:

> So, after digging around in the old llvm/ADT/hash_map, I think I
> discovered the problem.  Now, if you want to include
> llvm/ADT/HashExtras.h, you have to include the hash_map h file from  
> your
> system (ext/hash_map in my case) and define HASH_NAMESPACE, before you
> include llvm/ADT/HashExtras.  It might be good to include some
> documentation about that for those using HashExtras.

Hi Ryan,

Thanks for bringing this up.  HashExtras.h is an obsolete and dead  
header that was around from when we had hashmap and hashset wrappers.   
I have removed it from mainline.

-Chris

From clattner at apple.com  Tue Oct 13 00:36:04 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 12 Oct 2009 22:36:04 -0700
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
	<6d9073030910121601q1162138bs4eb5a222124a152e@mail.gmail.com>
	<54972E39-2E89-4B39-86B1-80E14CFF745A@apple.com>
	<6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>
Message-ID: <0DCFF8A0-C505-4E0C-ACD0-8DDA80C60EA7@apple.com>


On Oct 12, 2009, at 5:17 PM, Scott Ricketts wrote:

>> Hi Scott,
>>
>> Do you mean loop carried dependencies?  There is some initial work on
>> dependence analysis, but it is still pretty young.  We also have  
>> support for
>> dependence between memory operations that are not loop aware.
>>
>> -Chris
>
> I think the dependence analysis will have to be loop aware. For  
> example:

Okay, so the short answer is that we don't have what you need out of  
the box.

The longer answer is that there are two completely different types of  
loop dependences: memory dependences (load/store dependencies) and SSA  
value dependences like you're talking about here.

If you want to detect simple reductions like this, just walk the SSA  
graph starting from the PHIs in the loop header.  The code should look  
very similar to how LoopInfo identifies the canonical induction  
variable for a loop, it should not be difficult to write.

-Chris

>
> bb:
>        %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next, %bb ]
>        %sum = phi i32 [ 0, %bb.nph ], [ %3, %bb ]
>        %1 = getelementptr i32* %X, i64 %indvar
>        %2 = load i32* %1, align 4
>        %3 = add i32 %2, %sum
>        %indvar.next = add i64 %indvar, 1
>        %exitcond = icmp eq i64 %indvar.next, %tmp.
>        br i1 %exitcond, label %bb2, label %bb
>
> I would like to recognize that there is circular dependence (true and
> anti-) between %3 and %sum and that the only operations that form this
> dependence are associative+commutative (e.g. addition). In this
> example, we can see that by just looking at the operands of the %sum
> and %3 instructions. But things get more challenging when we toss in,
> say, a constant scalar multiply into each iteration. Then the
> dependencies have an intermediate operations between them:
>
> bb:
>        %indvar = phi i64 [ 0, %bb.nph ], [ %indvar.next, %bb ]
>        %sum = phi i32 [ 0, %bb.nph ], [ %3, %bb ]
>        %1 = getelementptr i32* %X, i64 %indvar
>        %2 = load i32* %1, align 4
>        %3 = mul i32 %2, 4
> %3 = add i32 %2, %sum
>        %indvar.next = add i64 %indvar, 1
>        %exitcond = icmp eq i64 %indvar.next, %tmp.
>        br i1 %exitcond, label %bb2, label %bb
>
> 1) %3 has a true dependency on %sum (this is trivial by just looking
> at the operands of the add inst)
> 2) %sum has an anti
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From bruno.cardoso at gmail.com  Tue Oct 13 00:42:08 2009
From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes)
Date: Tue, 13 Oct 2009 02:42:08 -0300
Subject: [LLVMdev] MIPS backend and VFPU
In-Reply-To: <994e72e3-c38c-4f28-96c5-07d8a24c96e1@x37g2000yqj.googlegroups.com>
References: <994e72e3-c38c-4f28-96c5-07d8a24c96e1@x37g2000yqj.googlegroups.com>
Message-ID: <275e64e40910122242y3bd2b2aat71d7e296aaf2aac9@mail.gmail.com>

Hi,

On Mon, Oct 12, 2009 at 11:23 AM, jetcube <pmlopes at gmail.com> wrote:
> I noticed that the MIPS backend was developed as a backend for the
> generic MIPS processor and also as a Google SoC targeting the Allegrex
> CPU, however there is no support for vector instructions. I see that
> vectorization is a very powerfull weapon from LLVM when compared to
> other compilers but in the case of the Allegrex CPU it is not
> supported. Are there any plans in the near future to add support for
> it?

Not that I'm aware of.
I may do that someday, but it's not in my plans for a near future,
but patches are always welcome! :)

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc

From baldrick at free.fr  Tue Oct 13 02:44:24 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 13 Oct 2009 09:44:24 +0200
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>
References: <200910121507.15755.dag@cray.com>
	<f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>
Message-ID: <4AD42FD8.6070309@free.fr>

Hi,

> On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote:
>> Are there any implicit assumptions about where alloca instructions
>> can appear.
> 
> Static allocas should appear as a continuous chunk in the entry block,
> otherwise other passes might make bad assumptions.

an alloca can appear anywhere, but when they are outside the entry block
then some optimizations may not occur.  The important distinction is
between alloca's that are appear in a loop and those that are not in a
loop.  Rather than detect loops, optimizers tend to just check whether
alloca's are in the entry block or not (the entry block is never part
of a loop).

Ciao,

Duncan.

From astifter-llvm at gmx.at  Tue Oct 13 02:51:10 2009
From: astifter-llvm at gmx.at (Andreas Neustifter)
Date: Tue, 13 Oct 2009 09:51:10 +0200
Subject: [LLVMdev] Use LoopInfo in a non-pass class such
	as	ProfileInfoLoader?
In-Reply-To: <2015205e0910061933m77ace1c0h429eb166449830ff@mail.gmail.com>
References: <2015205e0910061933m77ace1c0h429eb166449830ff@mail.gmail.com>
Message-ID: <4AD4316E.4010004@gmx.at>

Hi,

Wenhao Jia wrote:
> I'm adding loop profiling to LLVM built-in profiler. I'm just
> wondering in a class that's not a pass, such as ProfileInfoLoader, how
> can I get information produced by passes such as LoopInfo and
> DominatorTree?

I don't know if there is a Best Practice, but usually you have a pass
thats using the non-pass module (ProfileInfoLoader in your case). I use
the getAnalysis in the pass and hand a reference to the analysis to the
non-pass module so it can use it.

Also its possible to hand a reference to the pass itself to the non-pass
class and use this reference to call getAnalysis (pseudo code!):

NonPassModule::someFunction (..., Pass *P) {
  ...
  SomeAnalysis SOA = P->getAnalysis<SomeAnalysis>();
  ...
}

SomePass::runOn... (...) {
  ...
  NonPassModule NPM;
  ...
  NPM.someFunction(..., this);
  ...
}

Hope that helps,

Andi

From lennart at augustsson.net  Tue Oct 13 04:02:44 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Tue, 13 Oct 2009 11:02:44 +0200
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <4AD42FD8.6070309@free.fr>
References: <200910121507.15755.dag@cray.com>
	<f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>
	<4AD42FD8.6070309@free.fr>
Message-ID: <f4876cd70910130202j20b27142g8c3baf807b57246b@mail.gmail.com>

And you really want your allocas in the entry block so they are
implemented by just stack pointer manipulation rather than calling
alloca().  The latter is slower, and there's also a bug that makes
calling alloca() not getting the alignment right (if it's > 8).

On Tue, Oct 13, 2009 at 9:44 AM, Duncan Sands <baldrick at free.fr> wrote:
> Hi,
>
>> On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote:
>>> Are there any implicit assumptions about where alloca instructions
>>> can appear.
>>
>> Static allocas should appear as a continuous chunk in the entry block,
>> otherwise other passes might make bad assumptions.
>
> an alloca can appear anywhere, but when they are outside the entry block
> then some optimizations may not occur. ?The important distinction is
> between alloca's that are appear in a loop and those that are not in a
> loop. ?Rather than detect loops, optimizers tend to just check whether
> alloca's are in the entry block or not (the entry block is never part
> of a loop).
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From dag at cray.com  Tue Oct 13 10:34:52 2009
From: dag at cray.com (David Greene)
Date: Tue, 13 Oct 2009 10:34:52 -0500
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <f4876cd70910130202j20b27142g8c3baf807b57246b@mail.gmail.com>
References: <200910121507.15755.dag@cray.com> <4AD42FD8.6070309@free.fr>
	<f4876cd70910130202j20b27142g8c3baf807b57246b@mail.gmail.com>
Message-ID: <200910131034.52777.dag@cray.com>

On Tuesday 13 October 2009 04:02, Lennart Augustsson wrote:
> And you really want your allocas in the entry block so they are
> implemented by just stack pointer manipulation rather than calling
> alloca().  The latter is slower, and there's also a bug that makes
> calling alloca() not getting the alignment right (if it's > 8).

Is there a bug number for that?  I wonder if that's what I'm hitting.

                                -Dave

From dag at cray.com  Tue Oct 13 10:36:06 2009
From: dag at cray.com (David Greene)
Date: Tue, 13 Oct 2009 10:36:06 -0500
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>
References: <200910121507.15755.dag@cray.com>
	<f5aa3e9b0910122012l16992a9eqfe0a16ec93fa28d6@mail.gmail.com>
Message-ID: <200910131036.07097.dag@cray.com>

On Monday 12 October 2009 22:12, Eli Friedman wrote:
> On Mon, Oct 12, 2009 at 1:07 PM, David Greene <dag at cray.com> wrote:
> > Are there any implicit assumptions about where alloca instructions
> > can appear.
>
> Static allocas should appear as a continuous chunk in the entry block,
> otherwise other passes might make bad assumptions.

Ok, we should document this.

> > The interesting thing about this testcase is that the extra instcombine
> > makes the test pass. ?If I omit it, the test fails. ?The only differences
> > in the asm are stack offsets, which leads me to believe that in the
> > failing test codegen is not accounting for all allocas properly.
>
> If running a testcase through -instcombine -instcombine gives a result
> that isn't identical to -instcombine, that's a bug.  Please file it if
> you have a reduced testcase.

No, hat's not what I'm doing.  I'm limiting the number of transformations
instcombine does to do a binary search and narrow down on the specific
transformation that causes the problem (or in this case, masks it).

                               -Dave



From dag at cray.com  Tue Oct 13 10:39:13 2009
From: dag at cray.com (David Greene)
Date: Tue, 13 Oct 2009 10:39:13 -0500
Subject: [LLVMdev] Detecting reduction operations
In-Reply-To: <0DCFF8A0-C505-4E0C-ACD0-8DDA80C60EA7@apple.com>
References: <6d9073030910091106l87af09chf83b545235af1441@mail.gmail.com>
	<6d9073030910121717w53e9c687jcb4528741255cedb@mail.gmail.com>
	<0DCFF8A0-C505-4E0C-ACD0-8DDA80C60EA7@apple.com>
Message-ID: <200910131039.13246.dag@cray.com>

On Tuesday 13 October 2009 00:36, Chris Lattner wrote:

> If you want to detect simple reductions like this, just walk the SSA
> graph starting from the PHIs in the loop header.  The code should look
> very similar to how LoopInfo identifies the canonical induction
> variable for a loop, it should not be difficult to write.

ScalarEvolution is another place to look for examples.  It discovers add 
recurrences today and altering the analysis slightly to detect in-register
reductions shouldn't be hard to do.

                               -Dave

From dag at cray.com  Tue Oct 13 10:44:35 2009
From: dag at cray.com (David Greene)
Date: Tue, 13 Oct 2009 10:44:35 -0500
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
	<f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
Message-ID: <200910131044.35637.dag@cray.com>

On Monday 12 October 2009 22:22, Eli Friedman wrote:

> > Now I understand that llvm can have any length integer, but I consider
> > turning a 64bit mul into multiple 65 bit instructions to be a ?bad?
> > optimization. This eventually expands to a 128bit multiply call(__multi3)
> > which I have absolutely no interest in supporting. So I?m wondering what
> > optimization might be the culprit here so I can disable it in this
> > situation.
>
> I'm pretty sure this is the fault of one of the loop passes (I forget
> which one off the top of my head).  

It's SCEV.  I have this very bit of code disabled in our tree for exactly the
reasons Micah gives.  Check out BinomialCoefficient is ScalarEvolution.cpp.

Here's the big hack we put in, which is just the code that used to be there
in 2.3:

  // We need at least W + T bits for the multiplication step
  // FIXME: A temporary hack; we round up the bitwidths
  // to the nearest power of 2 to be nice to the code generator.
  unsigned CalculationBits = 1U << Log2_32_Ceil(W + T);

  // Cray: Truncate to 64 bits.  It's what we did with LLVM 2.3 and
  // while it can create miscompilations in some cases if the
  // computation happens to overflow, it's no worse than what we did
  // before.
  if (CalculationBits > 64) {
    //return new SCEVCouldNotCompute();
    CalculationBits = 64;
    DEBUG(DOUT << "*** [dag] SEVERE WARNING: SCEV calculation truncated to 64 
                   bits, check for miscompilation! ***\n");
  }

I have never found a test where this actually causes a problem.  And we have
tens of thousands of tests.

It is very bad form to create wide arithmetic where none was there before.
This is one of the downfalls of SCEV but I consider it to be minor compared
to the benefits.

                                     -Dave


From Micah.Villmow at amd.com  Tue Oct 13 10:59:50 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 13 Oct 2009 08:59:50 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <200910131044.35637.dag@cray.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com><f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
	<200910131044.35637.dag@cray.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D80C9@ssanexmb2.amd.com>

David,
 Thanks for helping me figure out exactly where to put the check. I was
trying to do modifications in other parts of that function and it wasn't
working very well. I've attached a patch that parameterizes this and
allows it to be set from the commandline instead of hardcoding it.

Would it be possible to get this patch pushed into the tree?

Thanks,
Micah

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of David Greene
Sent: Tuesday, October 13, 2009 8:45 AM
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] 65bit integer math

On Monday 12 October 2009 22:22, Eli Friedman wrote:

> > Now I understand that llvm can have any length integer, but I
consider
> > turning a 64bit mul into multiple 65 bit instructions to be a 'bad'
> > optimization. This eventually expands to a 128bit multiply
call(__multi3)
> > which I have absolutely no interest in supporting. So I'm wondering
what
> > optimization might be the culprit here so I can disable it in this
> > situation.
>
> I'm pretty sure this is the fault of one of the loop passes (I forget
> which one off the top of my head).  

It's SCEV.  I have this very bit of code disabled in our tree for
exactly the
reasons Micah gives.  Check out BinomialCoefficient is
ScalarEvolution.cpp.

Here's the big hack we put in, which is just the code that used to be
there
in 2.3:

  // We need at least W + T bits for the multiplication step
  // FIXME: A temporary hack; we round up the bitwidths
  // to the nearest power of 2 to be nice to the code generator.
  unsigned CalculationBits = 1U << Log2_32_Ceil(W + T);

  // Cray: Truncate to 64 bits.  It's what we did with LLVM 2.3 and
  // while it can create miscompilations in some cases if the
  // computation happens to overflow, it's no worse than what we did
  // before.
  if (CalculationBits > 64) {
    //return new SCEVCouldNotCompute();
    CalculationBits = 64;
    DEBUG(DOUT << "*** [dag] SEVERE WARNING: SCEV calculation truncated
to 64 
                   bits, check for miscompilation! ***\n");
  }

I have never found a test where this actually causes a problem.  And we
have
tens of thousands of tests.

It is very bad form to create wide arithmetic where none was there
before.
This is one of the downfalls of SCEV but I consider it to be minor
compared
to the benefits.

                                     -Dave

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScalarEvolution.diff
Type: application/octet-stream
Size: 1112 bytes
Desc: ScalarEvolution.diff
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091013/767d3e41/attachment.obj 

From gohman at apple.com  Tue Oct 13 12:06:23 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 13 Oct 2009 10:06:23 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
	<f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
	<bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
Message-ID: <BCB33F2D-23C5-433D-9FB0-51BD06F39814@apple.com>


On Oct 12, 2009, at 9:42 PM, Jeffrey Yasskin wrote:

> On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
>> On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah <Micah.Villmow at amd.com 
>> > wrote:
>>> I have a test case(attached as fc_long.ll) that when run through the
>>> optimizer produces 65bit integer math(fc_long-opt.ll).
>>>
>>>
>>>
>>> Now I understand that llvm can have any length integer, but I  
>>> consider
>>> turning a 64bit mul into multiple 65 bit instructions to be a ?bad?
>>> optimization. This eventually expands to a 128bit multiply call 
>>> (__multi3)
>>> which I have absolutely no interest in supporting. So I?m  
>>> wondering what
>>> optimization might be the culprit here so I can disable it in this
>>> situation.
>>
>> I'm pretty sure this is the fault of one of the loop passes (I forget
>> which one off the top of my head).  It's worth noting that the
>> optimizer manages to eliminate the loop; computing the exit value of
>> one of the loop variables uses the wide multiply.
>
> It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your
> input and got the attached file. I thought I could add "nuw nsw" to
> the arithmetic inside the loop to say that i65 is unnecessary, but
> that doesn't cause indvars to leave the arithmetic at i64. Is that a
> bug in indvars, or in SCEV, or is this just a natural limitation of
> SCEV?

LLVM's ScalarEvolution's handling of non-linear recurrences has much  
room
for improvement. The problem Micah describes sounds like the one
in lib/Analysis/README.txt.

Dan



From Micah.Villmow at amd.com  Tue Oct 13 15:23:08 2009
From: Micah.Villmow at amd.com (Villmow, Micah)
Date: Tue, 13 Oct 2009 13:23:08 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <BCB33F2D-23C5-433D-9FB0-51BD06F39814@apple.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com><f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com><bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
	<BCB33F2D-23C5-433D-9FB0-51BD06F39814@apple.com>
Message-ID: <493720826E33B1459E7F5C253E6D4BB58D81A8@ssanexmb2.amd.com>

What does nsw nuw do?

Micah

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Dan Gohman
Sent: Tuesday, October 13, 2009 10:06 AM
To: Jeffrey Yasskin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] 65bit integer math


On Oct 12, 2009, at 9:42 PM, Jeffrey Yasskin wrote:

> On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
>> On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah
<Micah.Villmow at amd.com 
>> > wrote:
>>> I have a test case(attached as fc_long.ll) that when run through the
>>> optimizer produces 65bit integer math(fc_long-opt.ll).
>>>
>>>
>>>
>>> Now I understand that llvm can have any length integer, but I  
>>> consider
>>> turning a 64bit mul into multiple 65 bit instructions to be a 'bad'
>>> optimization. This eventually expands to a 128bit multiply call 
>>> (__multi3)
>>> which I have absolutely no interest in supporting. So I'm  
>>> wondering what
>>> optimization might be the culprit here so I can disable it in this
>>> situation.
>>
>> I'm pretty sure this is the fault of one of the loop passes (I forget
>> which one off the top of my head).  It's worth noting that the
>> optimizer manages to eliminate the loop; computing the exit value of
>> one of the loop variables uses the wide multiply.
>
> It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your
> input and got the attached file. I thought I could add "nuw nsw" to
> the arithmetic inside the loop to say that i65 is unnecessary, but
> that doesn't cause indvars to leave the arithmetic at i64. Is that a
> bug in indvars, or in SCEV, or is this just a natural limitation of
> SCEV?

LLVM's ScalarEvolution's handling of non-linear recurrences has much  
room
for improvement. The problem Micah describes sounds like the one
in lib/Analysis/README.txt.

Dan


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




From jyasskin at google.com  Tue Oct 13 16:05:03 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Tue, 13 Oct 2009 14:05:03 -0700
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D81A8@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com>
	<f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com>
	<bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>
	<BCB33F2D-23C5-433D-9FB0-51BD06F39814@apple.com>
	<493720826E33B1459E7F5C253E6D4BB58D81A8@ssanexmb2.amd.com>
Message-ID: <bb55930e0910131405g36d82e53x4afa275d430878b0@mail.gmail.com>

"no [un]signed wrapping": http://llvm.org/docs/LangRef.html#i_add

On Tue, Oct 13, 2009 at 1:23 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote:
> What does nsw nuw do?
>
> Micah
>
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Dan Gohman
> Sent: Tuesday, October 13, 2009 10:06 AM
> To: Jeffrey Yasskin
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] 65bit integer math
>
>
> On Oct 12, 2009, at 9:42 PM, Jeffrey Yasskin wrote:
>
>> On Mon, Oct 12, 2009 at 8:22 PM, Eli Friedman
>> <eli.friedman at gmail.com> wrote:
>>> On Mon, Oct 12, 2009 at 6:15 PM, Villmow, Micah
> <Micah.Villmow at amd.com
>>> > wrote:
>>>> I have a test case(attached as fc_long.ll) that when run through the
>>>> optimizer produces 65bit integer math(fc_long-opt.ll).
>>>>
>>>>
>>>>
>>>> Now I understand that llvm can have any length integer, but I
>>>> consider
>>>> turning a 64bit mul into multiple 65 bit instructions to be a 'bad'
>>>> optimization. This eventually expands to a 128bit multiply call
>>>> (__multi3)
>>>> which I have absolutely no interest in supporting. So I'm
>>>> wondering what
>>>> optimization might be the culprit here so I can disable it in this
>>>> situation.
>>>
>>> I'm pretty sure this is the fault of one of the loop passes (I forget
>>> which one off the top of my head). ?It's worth noting that the
>>> optimizer manages to eliminate the loop; computing the exit value of
>>> one of the loop variables uses the wide multiply.
>>
>> It's -indvars. I ran mem2reg, instcombine, and simplifycfg on your
>> input and got the attached file. I thought I could add "nuw nsw" to
>> the arithmetic inside the loop to say that i65 is unnecessary, but
>> that doesn't cause indvars to leave the arithmetic at i64. Is that a
>> bug in indvars, or in SCEV, or is this just a natural limitation of
>> SCEV?
>
> LLVM's ScalarEvolution's handling of non-linear recurrences has much
> room
> for improvement. The problem Micah describes sounds like the one
> in lib/Analysis/README.txt.
>
> Dan
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From lennart at augustsson.net  Tue Oct 13 17:05:46 2009
From: lennart at augustsson.net (Lennart Augustsson)
Date: Wed, 14 Oct 2009 00:05:46 +0200
Subject: [LLVMdev] Alloca Requirements
In-Reply-To: <200910131034.52777.dag@cray.com>
References: <200910121507.15755.dag@cray.com> <4AD42FD8.6070309@free.fr>
	<f4876cd70910130202j20b27142g8c3baf807b57246b@mail.gmail.com>
	<200910131034.52777.dag@cray.com>
Message-ID: <f4876cd70910131505l25603622o3d35074dbb8e79c9@mail.gmail.com>

It's #4422.

On Tue, Oct 13, 2009 at 5:34 PM, David Greene <dag at cray.com> wrote:
> On Tuesday 13 October 2009 04:02, Lennart Augustsson wrote:
>> And you really want your allocas in the entry block so they are
>> implemented by just stack pointer manipulation rather than calling
>> alloca(). ?The latter is slower, and there's also a bug that makes
>> calling alloca() not getting the alignment right (if it's > 8).
>
> Is there a bug number for that? ?I wonder if that's what I'm hitting.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From plmdvy at gmail.com  Tue Oct 13 18:36:11 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Tue, 13 Oct 2009 23:36:11 +0000
Subject: [LLVMdev] AuroraUX detection in configure.ac
Message-ID: <9430ad070910131636k5845acf8mf9aa3dab815bcd0d@mail.gmail.com>

for evocallaghan he needed his configure.ac changes autogened.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091013/a6819944/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auroraux.patch
Type: text/x-patch
Size: 9003 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091013/a6819944/attachment.bin 

From eocallaghan at auroraux.org  Tue Oct 13 19:45:20 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Wed, 14 Oct 2009 01:45:20 +0100
Subject: [LLVMdev] AuroraUX detection in configure.ac
In-Reply-To: <9430ad070910131636k5845acf8mf9aa3dab815bcd0d@mail.gmail.com>
References: <9430ad070910131636k5845acf8mf9aa3dab815bcd0d@mail.gmail.com>
Message-ID: <521640720910131745x66f53929r4b989c7e4076d21f@mail.gmail.com>

Committed in revision 84067.

Many Thanks,
Edward.

2009/10/14 Paul Davey <plmdvy at gmail.com>:
> for evocallaghan he needed his configure.ac changes autogened.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From evan.cheng at apple.com  Wed Oct 14 00:59:38 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Tue, 13 Oct 2009 22:59:38 -0700
Subject: [LLVMdev] VLIW Scheduling Redux
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B277476B83D5@NAMAIL.ad.onsemi.com>
References: <8F2E4A8BCDA0B84DA6C9088EB5B277476B83D5@NAMAIL.ad.onsemi.com>
Message-ID: <B90C5C27-BB2D-4873-AF17-52E777D88AFD@apple.com>


On Oct 7, 2009, at 8:21 AM, Ken Dyck wrote:

> Have there been any developments in the codegen/scheduling
> infrastructure that would invalidate the advice given in this thread
> from September 2005?
> 
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-September/004798.html

Not really. You will still have to add a functional unit assignment and packing pass after pre-allocation scheduling.

Evan

> 
> -Ken
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



From plmdvy at gmail.com  Wed Oct 14 01:57:23 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Wed, 14 Oct 2009 06:57:23 +0000
Subject: [LLVMdev] undoing the pthread changes
Message-ID: <9430ad070910132357j4b0bc71v7c0f34995b045de7@mail.gmail.com>

Pthread search changes broke freebsd so they are coming out until something
better can be done
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/238683da/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undopthread.patch
Type: text/x-patch
Size: 4322 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/238683da/attachment.bin 

From nicolas at capens.net  Wed Oct 14 02:21:26 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Wed, 14 Oct 2009 09:21:26 +0200
Subject: [LLVMdev] Moving dependent code into conditional statements
Message-ID: <000601ca4c9e$f1861340$d49239c0$@net>

Hi all,

 

Is there any existing optimization pass that will move as much code into the
body of a forward branch as possible? Consider the following example:

 

int foo(int x)

{

    for(int i = 0; i < 1000000; i++)

    {

        int y = (x + 1) / x;   // Expensive calculation! Result written to
memory.

 

        if(x == 0)   // Forward branch

        {

            x = y;   // Body

        }

    }

  

    return x;

}

 

It appears that LLVM compiles this quite literally, performing the expensive
calculation a million times. Yet it could be rewritten like this:

 

int foo(int x)

{

    for(int i = 0; i < 1000000; i++)

    {

        if(x == 0)   // Unlikely to hit

        {

            int y = (x + 1) / x;

            x = y;

        }

    }

  

    return x;

}

 

This runs way faster.

 

I noticed there's a loop hoisting optimization (moving as many independent
operations out of the body of a backward branch), but I'm looking for its
twin. Did I overlook it or is it not yet supported?

 

Thanks,

 

Nicolas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/e7f5f18d/attachment.html 

From da.waterworth at googlemail.com  Wed Oct 14 03:14:35 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Wed, 14 Oct 2009 09:14:35 +0100
Subject: [LLVMdev] building llvm-gcc/llvm-g++
Message-ID: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>

Hi,

I'm having trouble building the llvm-gcc frontend. I'm working with
llvm-gcc4.2-2.5. I'm on 32bit x86 linux. I removed the file GNUmakefile,
then built it with:

./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5
make

~/llvm/backend/llvm-2.5 is where the backend was untared and built, but not
installed.

After I'd done this there was a file in host-i686-pc-linux-gnu/gcc called
xgcc. If I try to build with this however it won't accept the --emit-llvm
option with the error message:

xgcc: --emit-llvm is not supported in this configuration.

What option should I change in the configure command to get it to build in
such a way that "--emit-llvm" will work?

Thanks,

Daniel Waterworth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/34fed8e5/attachment.html 

From baldrick at free.fr  Wed Oct 14 03:32:15 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 14 Oct 2009 10:32:15 +0200
Subject: [LLVMdev] 65bit integer math
In-Reply-To: <493720826E33B1459E7F5C253E6D4BB58D81A8@ssanexmb2.amd.com>
References: <493720826E33B1459E7F5C253E6D4BB58D8028@ssanexmb2.amd.com><f5aa3e9b0910122022n1a1a0555pbd5b2a5d9ba7ef5f@mail.gmail.com><bb55930e0910122142u1915e3d7jd97fa4c918c865d6@mail.gmail.com>	<BCB33F2D-23C5-433D-9FB0-51BD06F39814@apple.com>
	<493720826E33B1459E7F5C253E6D4BB58D81A8@ssanexmb2.amd.com>
Message-ID: <4AD58C8F.20102@free.fr>

Villmow, Micah wrote:
> What does nsw nuw do?

It means it doesn't overflow whether considered signed or unsigned.  For
example, in i8 arithmetic, 255+1 overflows in the unsigned sense, while
127+1 overflows in the signed sense.  nsw nuw means neither of these
happens.

Ciao,

Duncan.

From anton at korobeynikov.info  Wed Oct 14 03:47:04 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Wed, 14 Oct 2009 12:47:04 +0400
Subject: [LLVMdev] building llvm-gcc/llvm-g++
In-Reply-To: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>
References: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>
Message-ID: <b087fca00910140147m6080525bped9e82ee601951c@mail.gmail.com>

Hello

> ./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5
> make
Please consider reading the documentation. E.g.
http://llvm.org/docs/GCCFEBuildInstrs.html

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From baldrick at free.fr  Wed Oct 14 04:02:30 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 14 Oct 2009 11:02:30 +0200
Subject: [LLVMdev] building llvm-gcc/llvm-g++
In-Reply-To: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>
References: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>
Message-ID: <4AD593A6.5030402@free.fr>

Hi Daniel,

> I'm having trouble building the llvm-gcc frontend. I'm working with 
> llvm-gcc4.2-2.5. I'm on 32bit x86 linux. I removed the file GNUmakefile, 
> then built it with:
> 
> ./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5

it's --enable-llvm, not --with-llvm.

Ciao,

Duncan.

From da.waterworth at googlemail.com  Wed Oct 14 04:09:21 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Wed, 14 Oct 2009 10:09:21 +0100
Subject: [LLVMdev] building llvm-gcc/llvm-g++
In-Reply-To: <4AD593A6.5030402@free.fr>
References: <7a5a555b0910140114w5d170d22ua95e7111d30e341a@mail.gmail.com>
	<4AD593A6.5030402@free.fr>
Message-ID: <7a5a555b0910140209v4ec6dae9hb9b4faddec93dcd3@mail.gmail.com>

2009/10/14 Duncan Sands <baldrick at free.fr>

> Hi Daniel,
>
>  I'm having trouble building the llvm-gcc frontend. I'm working with
>> llvm-gcc4.2-2.5. I'm on 32bit x86 linux. I removed the file GNUmakefile,
>> then built it with:
>>
>> ./configure --enable-languages=c,c++ --with-llvm=~/llvm/backend/llvm-2.5
>>
>
> it's --enable-llvm, not --with-llvm.
>
> Ciao,
>
> Duncan.
>

Great, thanks a lot, I shall build again with that option.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/c6eeba19/attachment.html 

From plmdvy at gmail.com  Wed Oct 14 04:54:34 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Wed, 14 Oct 2009 09:54:34 +0000
Subject: [LLVMdev] undoing the pthread changes
In-Reply-To: <9430ad070910132357j4b0bc71v7c0f34995b045de7@mail.gmail.com>
References: <9430ad070910132357j4b0bc71v7c0f34995b045de7@mail.gmail.com>
Message-ID: <9430ad070910140254q736d41e2td9fca029dee53e4e@mail.gmail.com>

I got two arguments the wrong way round, this is the fixed one

On Wed, Oct 14, 2009 at 6:57 AM, Paul Davey <plmdvy at gmail.com> wrote:

> Pthread search changes broke freebsd so they are coming out until something
> better can be done
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/e85b56d4/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undopthread.patch
Type: text/x-patch
Size: 4091 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/e85b56d4/attachment.bin 

From eocallaghan at auroraux.org  Wed Oct 14 06:13:10 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Wed, 14 Oct 2009 12:13:10 +0100
Subject: [LLVMdev] undoing the pthread changes
In-Reply-To: <9430ad070910140254q736d41e2td9fca029dee53e4e@mail.gmail.com>
References: <9430ad070910132357j4b0bc71v7c0f34995b045de7@mail.gmail.com>
	<9430ad070910140254q736d41e2td9fca029dee53e4e@mail.gmail.com>
Message-ID: <521640720910140413k4cb17d77od7607dc4061755c8@mail.gmail.com>

Committed in revision 84083.

Many thanks,
Edward.

2009/10/14 Paul Davey <plmdvy at gmail.com>:
> I got two arguments the wrong way round, this is the fixed one
>
> On Wed, Oct 14, 2009 at 6:57 AM, Paul Davey <plmdvy at gmail.com> wrote:
>>
>> Pthread search changes broke freebsd so they are coming out until
>> something better can be done
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From jklumpp0 at gmail.com  Wed Oct 14 07:31:56 2009
From: jklumpp0 at gmail.com (Joseph Klumpp)
Date: Wed, 14 Oct 2009 08:31:56 -0400
Subject: [LLVMdev] GlobalValue.h:116 error
Message-ID: <dccad1de0910140531w5d5e3ba1je7179b0aff61d5d1@mail.gmail.com>

When I attempt to follow any tutorial for llvm and add the `llvm-config
--cxxflags --ldflags --libs all` line to my GXX_FLAGS, g++ chokes on
llvm/GlobalValue.h, complaining of an invalid cast from int to
llvm::GlobalValue::LinkageTypes. I receive this error under both Red Hat and
Ubuntu and the version of G++ I am using is 4.1.2.
Thanks in advance,
Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/00b87370/attachment.html 

From samuraileumas at yahoo.com  Wed Oct 14 10:13:50 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 14 Oct 2009 08:13:50 -0700 (PDT)
Subject: [LLVMdev] Fw:  GlobalValue.h:116 error
In-Reply-To: <dccad1de0910140531w5d5e3ba1je7179b0aff61d5d1@mail.gmail.com>
References: <dccad1de0910140531w5d5e3ba1je7179b0aff61d5d1@mail.gmail.com>
Message-ID: <344700.99108.qm@web62008.mail.re1.yahoo.com>

Oops, forgot to reply to all.


>
>----- Forwarded Message ----
>From: Samuel Crow <samuraileumas at yahoo.com>
>To: Joseph Klumpp <jklumpp0 at gmail.com>
>Sent: Wed, October 14, 2009 10:12:45 AM
>Subject: Re: [LLVMdev] GlobalValue.h:116 error
>
>
>http://llvm.org/docs/GettingStarted.html#brokengcc indicates that that version of G++ will only compile properly using -O0 (optimization disabled).
>
>
>>
>>From: Joseph Klumpp <jklumpp0 at gmail.com>
>>To: llvmdev at cs.uiuc.edu
>>Sent: Wed, October 14, 2009 7:31:56
>> AM
>>Subject: [LLVMdev] GlobalValue.h:116 error
>>
>>>> When I attempt to follow any tutorial for llvm and add the `llvm-config --cxxflags --ldflags --libs all` line to my GXX_FLAGS, g++ chokes on llvm/GlobalValue.h, complaining of an invalid cast from int to llvm::GlobalValue::LinkageTypes. I receive this error under both Red Hat and Ubuntu and the version of G++ I am using is 4.1.2. 
>>
>>
>>Thanks in advance,
>>Jared
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/5de3d31d/attachment.html 

From clattner at apple.com  Wed Oct 14 10:22:53 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 08:22:53 -0700
Subject: [LLVMdev] Moving dependent code into conditional statements
In-Reply-To: <000601ca4c9e$f1861340$d49239c0$@net>
References: <000601ca4c9e$f1861340$d49239c0$@net>
Message-ID: <66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>


On Oct 14, 2009, at 12:21 AM, Nicolas Capens wrote:

> Hi all,
>
> Is there any existing optimization pass that will move as much code  
> into the body of a forward branch as possible? Consider the  
> following example:

Hi Nicolas,

Instcombine does this in simple cases (see "See if we can trivially  
sink this instruction to a successor basic block.") but it misses this  
case because the if gets folded into a select early.  It was also not  
handling the "phi use" case very aggressively, which I fixed in  
r84103.  We now sink the divide and add in this example:

int foo(int x)
{
     for(int i = 0; i < 1000000; i++)
     {
         int y = (x + 1) / x;   // Expensive calculation! Result  
written to memory.

         if(x == 0)   // Forward branch
         {
bar();
             x = y;   // Body
         }
     }

     return x;
}


-Chris


>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         int y = (x + 1) / x;   // Expensive calculation! Result  
> written to memory.
>
>         if(x == 0)   // Forward branch
>         {
>             x = y;   // Body
>         }
>     }
>
>     return x;
> }
>
> It appears that LLVM compiles this quite literally, performing the  
> expensive calculation a million times. Yet it could be rewritten  
> like this:
>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         if(x == 0)   // Unlikely to hit
>         {
>             int y = (x + 1) / x;
>             x = y;
>         }
>     }
>
>     return x;
> }
>
> This runs way faster.
>
> I noticed there?s a loop hoisting optimization (moving as many  
> independent operations out of the body of a backward branch), but  
> I?m looking for its twin. Did I overlook it or is it not yet  
> supported?
>
> Thanks,
>
> Nicolas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/c60a1b3d/attachment-0001.html 

From 49640f8a at gmail.com  Wed Oct 14 10:35:15 2009
From: 49640f8a at gmail.com (Martins Mozeiko)
Date: Wed, 14 Oct 2009 18:35:15 +0300
Subject: [LLVMdev] Fwd: JIT on ARM
References: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
Message-ID: <1ED6ADF5-F12B-4727-8507-DDA13EE173FA@gmail.com>

Hi.
Sorry for reposting my mail, but can somebody at lest give some  
general ideas for what to look to solve my problem?

--
Martins Mozeiko


Begin forwarded message:

> From: Martins Mozeiko <49640f8a at gmail.com>
> Date: September 25, 2009 12:04:04 GMT+03:00
> To: llvmdev at cs.uiuc.edu
> Subject: JIT on ARM
>
> Hello.
>
> My goal is to use LLVM with JIT compiler for ARM on Android device.
>
> Currently I have successfully built and executed LLVM bitcode with  
> interpreter on Android. Speed is not so great, that is why I want to  
> use JIT.
> I tried building bitcode on windows with llvm-gcc that is provided  
> on llvm home page. Resulting bitcode runs great in interpreter, but  
> it doesn't use JIT. From what I understand from LLVM that it is  
> because of target triple or datalayout. On PC in my case target  
> triple is "i386-mingw32", but LLVM JIT for ARM expects something  
> that starts with "armv" or "thumb". Also datalayout differs a lot.  
> If I understand correctly that is because bitcode actually contains  
> some of platform specific optimizations (like integer endianness),  
> so I can't simply change target triple string and everything will run.
>
> What I am now doing, is - I am trying to build gcc from gcc-4.2- 
> llvm-2.5 sources with following configure line in cygwin shell:
>
> ../llvm-gcc4.2-2.4.source/configure --enable-languages=c,c++ -- 
> enable-checking --enable-llvm=$PWD/../llvm-objects --disable- 
> bootstrap --disable-multilib --disable-nls --target=arm-eabi
>
> My undertanding is that this will produce llvm-gcc compiler that  
> will output LLVM bitcode with target triple that starts with "arm",  
> so LLVM will use JIT on it.
>
> Currently I am getting compile problems when running make (see below).
> Has anyone done something similar and can explain what I am doing  
> wrong, or how should it be done in some other way to get JIT  
> compiler running on ARM?
>
>
> make[2]: Entering directory `/cygdrive/r/android/llvm/llvm-gcc4.2- 
> objects/gcc'
> gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite- 
> strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long- 
> long -Wno-variadic-macros -Wno-overlength-strings -Wold-style- 
> definition -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H - 
> DGENERATOR_FILE  -o build/gengtype.exe \
>            build/gengtype.o build/gengtype-lex.o build/gengtype- 
> yacc.o build/errors.o ../build-i686-pc-cygwin/libiberty/libiberty.a
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:763: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:771: undefined reference to  
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_tree_exp':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:713: undefined reference to  
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_rtx_def':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:488: undefined reference to  
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:785: undefined reference to  
> `_lexer_line'
> build/gengtype.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/ 
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype.c:725: more undefined  
> references to `_lexer_line' follow
> build/gengtype.o: In function `main':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to  
> `_parse_file'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to  
> `_parse_file'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:73: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:75: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:76: undefined reference to  
> `_lexer_toplevel_done'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
> 1873: undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
> 1379: undefined reference to `_yylex'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
> 1877: undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
> 1995: undefined reference to `_yyerror'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:122: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:110: undefined reference to  
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:102: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:97: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:92: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:239: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:235: undefined reference to  
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/ 
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:231: more  
> undefined references to `_lexer_line' follow
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:84: undefined reference to  
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to  
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm- 
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: undefined reference to  
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/ 
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: more  
> undefined references to `_lexer_line' follow
> collect2: ld returned 1 exit status
> make[2]: *** [build/gengtype.exe] Error 1
>
> --
> Martins Mozeiko
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/80a9cba9/attachment.html 

From samuraileumas at yahoo.com  Wed Oct 14 11:19:03 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Wed, 14 Oct 2009 09:19:03 -0700 (PDT)
Subject: [LLVMdev] Moving dependent code into conditional statements
In-Reply-To: <66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
References: <000601ca4c9e$f1861340$d49239c0$@net>
	<66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
Message-ID: <455207.16416.qm@web62008.mail.re1.yahoo.com>

Hi Nicolas,

Your example has more expense in that calculation than you may have intended.  Why are you trying to divide by 0?  It seems to me that that would trigger an exception on any processor I know of.  :-)  No wonder it's faster to execute in the if statement!

That being said, would llvm-gcc or clang have a way to figure stuff like that divide by zero out before you execute the code and get the exception?

--Sam


>
>From: Chris Lattner <clattner at apple.com>
>To: Nicolas Capens <nicolas at capens.net>
>Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>Sent: Wed, October 14, 2009 10:22:53 AM
>Subject: Re: [LLVMdev] Moving dependent code into conditional statements
>
>
>
>On Oct 14, 2009, at 12:21 AM, Nicolas Capens wrote:
>
>Hi all,
>> 
>>Is there any existing optimization pass that will move as much code into the body of a forward branch as possible? Consider the following example:
>
>
>Hi Nicolas,
>
>
>Instcombine does this in simple cases (see "See if we can trivially sink this instruction to a successor basic block.") but it misses this case because the if gets folded into a select early.  It was also not handling the "phi use" case very aggressively, which I fixed in r84103.  We now sink the divide and add in this example:
>
>
>int foo(int x)
>{
>    for(int i = 0; i < 1000000; i++)
>    {
>        int y = (x + 1) / x;   // Expensive calculation! Result written to memory.
> 
>        if(x == 0)   // Forward branch
>        {
>bar();
>            x = y;   // Body
>        }
>    }
> 
>    return x;
>}
>
>
>
>
>-Chris
>
>
>
> 
>>int foo(int x)
>>{
>>    for(int i = 0; i < 1000000; i++)
>>    {
>>        int y = (x + 1) / x;   // Expensive calculation! Result written to memory.
>> 
>>        if(x == 0)   // Forward branch
>>        {
>>            x = y;   // Body
>>        }
>>    }
>> 
>>    return x;
>>}
>> 
>>It appears that LLVM compiles this quite literally, performing the expensive calculation a million times. Yet it could be rewritten like this:
>> 
>>int foo(int x)
>>{
>>    for(int i = 0; i < 1000000; i++)
>>    {
>>        if(x == 0)   // Unlikely to hit
>>        {
>>            int y = (x + 1) / x;
>>            x = y;
>>        }
>>    }
>> 
>>    return x;
>>}
>> 
>>This runs way faster.
>> 
>>I noticed there?s a loop hoisting optimization (moving as many independent operations out of the body of a backward branch), but I?m looking for its twin. Did I overlook it or is it not yet supported?
>> 
>>Thanks,
>> 
>>Nicolas
_______________________________________________
>>LLVM Developers mailing list
>>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/0fa4adbb/attachment.html 

From baldrick at free.fr  Wed Oct 14 11:19:34 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 14 Oct 2009 18:19:34 +0200
Subject: [LLVMdev] Fwd: JIT on ARM
In-Reply-To: <1ED6ADF5-F12B-4727-8507-DDA13EE173FA@gmail.com>
References: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
	<1ED6ADF5-F12B-4727-8507-DDA13EE173FA@gmail.com>
Message-ID: <4AD5FA16.1070504@free.fr>

Hi Martins,

>> I tried building bitcode on windows with llvm-gcc that is provided on 
>> llvm home page. Resulting bitcode runs great in interpreter, but it 
>> doesn't use JIT. From what I understand from LLVM that it is because 
>> of target triple or datalayout. On PC in my case target triple is 
>> "i386-mingw32", but LLVM JIT for ARM expects something that starts 
>> with "armv" or "thumb". Also datalayout differs a lot. If I understand 
>> correctly that is because bitcode actually contains some of platform 
>> specific optimizations (like integer endianness), so I can't simply 
>> change target triple string and everything will run.

as you have understood, the JIT requires bitcode that targets the
machine you are jiting on, so you need to cross-compile for arm.
I don't know anything about cross-compiling, for example whether
it is possible and whether you are doing it right - hopefully one
of the arm guys can help you out.

Ciao,

Duncan.

>> What I am now doing, is - I am trying to build gcc from 
>> gcc-4.2-llvm-2.5 sources with following configure line in cygwin shell:
>>
>> ../llvm-gcc4.2-2.4.source/configure --enable-languages=c,c++ 
>> --enable-checking --enable-llvm=$PWD/../llvm-objects 
>> --disable-bootstrap --disable-multilib --disable-nls --target=arm-eabi
>>
>> My undertanding is that this will produce llvm-gcc compiler that will 
>> output LLVM bitcode with target triple that starts with "arm", so LLVM 
>> will use JIT on it.
>>
>> Currently I am getting compile problems when running make (see below).
>> Has anyone done something similar and can explain what I am doing 
>> wrong, or how should it be done in some other way to get JIT compiler 
>> running on ARM?
>>
>>
>> make[2]: Entering directory 
>> `/cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc'
>> gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall 
>> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
>> -Wold-style-definition -Wmissing-format-attribute -fno-common 
>>   -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengtype.exe \
>>            build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o 
>> build/errors.o ../build-i686-pc-cygwin/libiberty/libiberty.a
>> build/gengtype.o: In function `adjust_field_type':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype.c:763: 
>> undefined reference to `_lexer_line'
...


From stuart at apple.com  Wed Oct 14 11:35:23 2009
From: stuart at apple.com (Stuart Hastings)
Date: Wed, 14 Oct 2009 09:35:23 -0700
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <E9913FC3-B4C3-4264-8EFF-328E2B4C4CC4@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
	<A0929213-3743-4093-9337-FE441F24C893@apple.com>
	<2896E598-AED0-49D3-8854-63892F333386@apple.com>
	<E9913FC3-B4C3-4264-8EFF-328E2B4C4CC4@apple.com>
Message-ID: <4C796CBB-C33B-49BA-8B58-EEA4E945F1DA@apple.com>


On Oct 9, 2009, at 12:34 PM, Mike Stump wrote:

>
> On Oct 9, 2009, at 8:40 AM, Stuart Hastings wrote:
>
>>
>> On Oct 8, 2009, at 5:18 PM, Mike Stump wrote:
>>
>>> On Oct 8, 2009, at 4:52 PM, Stuart Hastings wrote:
>>>> Currently, to get LLVM to build "Apple-style," it's necessary to  
>>>> copy two files (utils/buildit/GNUmakefile and utils/buildit/ 
>>>> build_llvm) into the top-level directory.
>>>
>>> Why not:
>>>
>>> $ RC_ARCHS="x86" make
>>> echo Apple Build.
>>> Apple Build.
>>> $ make
>>> echo Standard Build
>>> Standard Build
>>> $ cat Makefile
>>> ifneq ($(RC_ARCHS),)
>>> include Makefile.apple
>>> else
>>> all:
>>> 	echo Standard Build
>>> endif
>>> mrs $ cat Makefile.apple
>>> all:
>>> 	echo Apple Build.
>>>
>>> It leaves Makefile mostly alone, all except for three lines at the  
>>> top and one line at the end of it.
>>
>> Because the existing top-level Makefile includes "Makefile.config".
>
> ?  Only if you want it:
>
> $ cat Makefile
> ifdef FOO
> include no_such_file
> endif
>
>
> all:
> 	echo ok
> mrs $ make all
> echo ok
> ok

I don't think that solves the problem.  If I elide both of the  
includes in the top-level Makefile, then I'm obliged to make the  
combined Makefile + included GNUmakefile coexist.  I think it could be  
done, but I'd rather not.  :-)  The alternative is to wrap the entire  
body of the top-level Makefile in a conditional.  IMHO this is uglier  
and more fragile than my original proposal, but it's still workable:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvmCore.diffs.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/98278eb6/attachment.txt 
-------------- next part --------------


stuart

From jklumpp0 at gmail.com  Wed Oct 14 12:00:02 2009
From: jklumpp0 at gmail.com (Joseph Klumpp)
Date: Wed, 14 Oct 2009 13:00:02 -0400
Subject: [LLVMdev] GlobalValue.h:116 error
In-Reply-To: <dccad1de0910140531w5d5e3ba1je7179b0aff61d5d1@mail.gmail.com>
References: <dccad1de0910140531w5d5e3ba1je7179b0aff61d5d1@mail.gmail.com>
Message-ID: <dccad1de0910141000r4ecc6ddcj59294848787b7fb5@mail.gmail.com>

I solved it by moving a project-specific include after the llvm includes.
I.e.,
From:

#include "ast.h"
#include "llvm/Module.h"
#include "llvm/Function.h"
#include "llvm/PassManager.h"
...

to:

#include "llvm/Module.h"
#include "llvm/Function.h"
#include "llvm/PassManager.h"
...
#include "ast.h"

I can't figure out why this gave me the particular error I was receiving,
but it solves the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/062fe994/attachment.html 

From grosbach at apple.com  Wed Oct 14 12:23:44 2009
From: grosbach at apple.com (Jim Grosbach)
Date: Wed, 14 Oct 2009 10:23:44 -0700
Subject: [LLVMdev] JIT on ARM
In-Reply-To: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
References: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
Message-ID: <60BA723D-5E1D-4F1C-838F-160C623EBE9A@apple.com>

Hi Martins,

There's two steps to get where you're wanting to go.

First, you need an ARM cross-compiler on your host so you can generate  
ARM bitcode. That's what you're building with your llvm-gcc you  
referenced. In my ARM configure lines, I explicitly specify --host and  
--build as well as --target, but that is more due to vagaries of my  
local environment and shouldn't be required for what you're doing.

Second, you need an ARM *hosted* LLVM build to actually do the JIT  
execution of the bytecode you've produced on the host. For that,  
you'll need a canadian-cross compile build of llvmCore. Have a  
separate objects build directory for llvm than you use for cross  
compiler since this will be ARM code, not x86 code. Specify "-- 
host=arm-eabi --build=i686-pc-cygwin --target=arm-eabi" on your  
configure line, and you should be able to generate an ARM-hosted LLVM  
toolset. Do note that this will require a set of ARM-target cross  
compiler tools to be on the path and ARM libraries to be available,  
just like building any other ARM code on your host. You'll see the  
configure script looking for tools like "arm-eabi-gcc" and such,  
probably. If it can't find them, things are unlikely to work.

Once you've built the ARM hosted LLVM, you can copy it over to your  
device (I NFS mount the directory, personally). Then you can run lli  
from there on bitcode and the ARM JIT should kick in and compile your  
code.

The errors you're seeing don't look familiar to me, unfortunately.   
lexer_line is defined in gengtype-lex.l. Perhaps there were issues  
running flex to generate the code from there? I would suggest looking  
in your build logs for where gengtype-lex.c and gengtype-lex.o are  
created to see if there are earlier problems that cascaded down to  
result in this link failure.

Regards,
   Jim

On Sep 25, 2009, at 2:04 AM, Martins Mozeiko wrote:

> Hello.
>
> My goal is to use LLVM with JIT compiler for ARM on Android device.
>
> Currently I have successfully built and executed LLVM bitcode with
> interpreter on Android. Speed is not so great, that is why I want to
> use JIT.
> I tried building bitcode on windows with llvm-gcc that is provided on
> llvm home page. Resulting bitcode runs great in interpreter, but it
> doesn't use JIT. From what I understand from LLVM that it is because
> of target triple or datalayout. On PC in my case target triple is
> "i386-mingw32", but LLVM JIT for ARM expects something that starts
> with "armv" or "thumb". Also datalayout differs a lot. If I understand
> correctly that is because bitcode actually contains some of platform
> specific optimizations (like integer endianness), so I can't simply
> change target triple string and everything will run.
>
> What I am now doing, is - I am trying to build gcc from gcc-4.2-
> llvm-2.5 sources with following configure line in cygwin shell:
>
> ../llvm-gcc4.2-2.4.source/configure --enable-languages=c,c++ --enable-
> checking --enable-llvm=$PWD/../llvm-objects --disable-bootstrap --
> disable-multilib --disable-nls --target=arm-eabi
>
> My undertanding is that this will produce llvm-gcc compiler that will
> output LLVM bitcode with target triple that starts with "arm", so LLVM
> will use JIT on it.
>
> Currently I am getting compile problems when running make (see below).
> Has anyone done something similar and can explain what I am doing
> wrong, or how should it be done in some other way to get JIT compiler
> running on ARM?
>
>
> make[2]: Entering directory `/cygdrive/r/android/llvm/llvm-gcc4.2-
> objects/gcc'
> gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-
> strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-
> long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-
> definition -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -
> DGENERATOR_FILE  -o build/gengtype.exe \
>             build/gengtype.o build/gengtype-lex.o build/gengtype-
> yacc.o build/errors.o ../build-i686-pc-cygwin/libiberty/libiberty.a
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:763: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:771: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_tree_exp':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:713: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_rtx_def':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:488: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:785: undefined reference to
> `_lexer_line'
> build/gengtype.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype.c:725: more undefined
> references to `_lexer_line' follow
> build/gengtype.o: In function `main':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
> `_parse_file'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
> `_parse_file'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:73: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:75: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:76: undefined reference to
> `_lexer_toplevel_done'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1873:
> undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1379:
> undefined reference to `_yylex'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1877:
> undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1995:
> undefined reference to `_yyerror'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:122: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:110: undefined reference to
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:102: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:97: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:92: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:239: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:235: undefined reference to
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:231: more
> undefined references to `_lexer_line' follow
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:84: undefined reference to
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: undefined reference to
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: more
> undefined references to `_lexer_line' follow
> collect2: ld returned 1 exit status
> make[2]: *** [build/gengtype.exe] Error 1
>
> --
> Martins Mozeiko
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From grosbach at apple.com  Wed Oct 14 12:27:15 2009
From: grosbach at apple.com (Jim Grosbach)
Date: Wed, 14 Oct 2009 10:27:15 -0700
Subject: [LLVMdev] JIT on ARM
In-Reply-To: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
References: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
Message-ID: <9F3A7182-F30F-4AEE-94E1-F110DCBEDE90@apple.com>

Forgot to mention. I don't know how well the canadian cross compile  
stuff works in 2.5. We made some improvements in that area for 2.6. If  
you have trouble with it, I'd suggest trying 2.6 (or even better, ToT  
svn) and seeing if things are improved there.


-Jim
On Sep 25, 2009, at 2:04 AM, Martins Mozeiko wrote:

> Hello.
>
> My goal is to use LLVM with JIT compiler for ARM on Android device.
>
> Currently I have successfully built and executed LLVM bitcode with
> interpreter on Android. Speed is not so great, that is why I want to
> use JIT.
> I tried building bitcode on windows with llvm-gcc that is provided on
> llvm home page. Resulting bitcode runs great in interpreter, but it
> doesn't use JIT. From what I understand from LLVM that it is because
> of target triple or datalayout. On PC in my case target triple is
> "i386-mingw32", but LLVM JIT for ARM expects something that starts
> with "armv" or "thumb". Also datalayout differs a lot. If I understand
> correctly that is because bitcode actually contains some of platform
> specific optimizations (like integer endianness), so I can't simply
> change target triple string and everything will run.
>
> What I am now doing, is - I am trying to build gcc from gcc-4.2-
> llvm-2.5 sources with following configure line in cygwin shell:
>
> ../llvm-gcc4.2-2.4.source/configure --enable-languages=c,c++ --enable-
> checking --enable-llvm=$PWD/../llvm-objects --disable-bootstrap --
> disable-multilib --disable-nls --target=arm-eabi
>
> My undertanding is that this will produce llvm-gcc compiler that will
> output LLVM bitcode with target triple that starts with "arm", so LLVM
> will use JIT on it.
>
> Currently I am getting compile problems when running make (see below).
> Has anyone done something similar and can explain what I am doing
> wrong, or how should it be done in some other way to get JIT compiler
> running on ARM?
>
>
> make[2]: Entering directory `/cygdrive/r/android/llvm/llvm-gcc4.2-
> objects/gcc'
> gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-
> strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-
> long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-
> definition -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -
> DGENERATOR_FILE  -o build/gengtype.exe \
>             build/gengtype.o build/gengtype-lex.o build/gengtype-
> yacc.o build/errors.o ../build-i686-pc-cygwin/libiberty/libiberty.a
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:763: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:771: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_tree_exp':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:713: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_rtx_def':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:488: undefined reference to
> `_lexer_line'
> build/gengtype.o: In function `adjust_field_type':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:785: undefined reference to
> `_lexer_line'
> build/gengtype.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype.c:725: more undefined
> references to `_lexer_line' follow
> build/gengtype.o: In function `main':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
> `_parse_file'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
> `_parse_file'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:73: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:75: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:76: undefined reference to
> `_lexer_toplevel_done'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1873:
> undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1379:
> undefined reference to `_yylex'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1877:
> undefined reference to `_yyerror'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c:1995:
> undefined reference to `_yyerror'
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:122: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:110: undefined reference to
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:102: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:97: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:92: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:239: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:235: undefined reference to
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:231: more
> undefined references to `_lexer_line' follow
> build/gengtype-yacc.o: In function `yyparse':
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:84: undefined reference to
> `_lexer_toplevel_done'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
> `_lexer_line'
> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
> gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: undefined reference to
> `_lexer_line'
> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: more
> undefined references to `_lexer_line' follow
> collect2: ld returned 1 exit status
> make[2]: *** [build/gengtype.exe] Error 1
>
> --
> Martins Mozeiko
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From vadve at illinois.edu  Wed Oct 14 12:54:35 2009
From: vadve at illinois.edu (Vikram S. Adve)
Date: Wed, 14 Oct 2009 12:54:35 -0500
Subject: [LLVMdev] Moving dependent code into conditional statements
In-Reply-To: <66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
References: <000601ca4c9e$f1861340$d49239c0$@net>
	<66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
Message-ID: <CD7A022E-13DF-4614-A89B-1D4B67032557@illinois.edu>

On Oct 14, 2009, at 10:22 AM, Chris Lattner wrote:

>
> On Oct 14, 2009, at 12:21 AM, Nicolas Capens wrote:
>
>> Hi all,
>>
>> Is there any existing optimization pass that will move as much code  
>> into the body of a forward branch as possible? Consider the  
>> following example:
>
> Hi Nicolas,
>
> Instcombine does this in simple cases


The general version of this looks like classical PRE.

--Vikram
Associate Professor, Computer Science
University of Illinois at Urbana-Champaign
http://llvm.org/~vadve



> (see "See if we can trivially sink this instruction to a successor  
> basic block.") but it misses this case because the if gets folded  
> into a select early.  It was also not handling the "phi use" case  
> very aggressively, which I fixed in r84103.  We now sink the divide  
> and add in this example:
>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         int y = (x + 1) / x;   // Expensive calculation! Result  
> written to memory.
>
>         if(x == 0)   // Forward branch
>         {
> bar();
>             x = y;   // Body
>         }
>     }
>
>     return x;
> }
>
>
> -Chris
>
>
>>
>> int foo(int x)
>> {
>>     for(int i = 0; i < 1000000; i++)
>>     {
>>         int y = (x + 1) / x;   // Expensive calculation! Result  
>> written to memory.
>>
>>         if(x == 0)   // Forward branch
>>         {
>>             x = y;   // Body
>>         }
>>     }
>>
>>     return x;
>> }
>>
>> It appears that LLVM compiles this quite literally, performing the  
>> expensive calculation a million times. Yet it could be rewritten  
>> like this:
>>
>> int foo(int x)
>> {
>>     for(int i = 0; i < 1000000; i++)
>>     {
>>         if(x == 0)   // Unlikely to hit
>>         {
>>             int y = (x + 1) / x;
>>             x = y;
>>         }
>>     }
>>
>>     return x;
>> }
>>
>> This runs way faster.
>>
>> I noticed there?s a loop hoisting optimization (moving as many  
>> independent operations out of the body of a backward branch), but  
>> I?m looking for its twin. Did I overlook it or is it not yet  
>> supported?
>>
>> Thanks,
>>
>> Nicolas
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> <ATT00001.txt>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/6dcdeee2/attachment.html 

From clattner at apple.com  Wed Oct 14 12:56:57 2009
From: clattner at apple.com (Chris Lattner)
Date: Wed, 14 Oct 2009 10:56:57 -0700
Subject: [LLVMdev] Moving dependent code into conditional statements
In-Reply-To: <CD7A022E-13DF-4614-A89B-1D4B67032557@illinois.edu>
References: <000601ca4c9e$f1861340$d49239c0$@net>
	<66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
	<CD7A022E-13DF-4614-A89B-1D4B67032557@illinois.edu>
Message-ID: <80115541-587D-4ECC-85A3-03F6561EA625@apple.com>


On Oct 14, 2009, at 10:54 AM, Vikram S. Adve wrote:

> On Oct 14, 2009, at 10:22 AM, Chris Lattner wrote:
>
>>
>> On Oct 14, 2009, at 12:21 AM, Nicolas Capens wrote:
>>
>>> Hi all,
>>>
>>> Is there any existing optimization pass that will move as much  
>>> code into the body of a forward branch as possible? Consider the  
>>> following example:
>>
>> Hi Nicolas,
>>
>> Instcombine does this in simple cases
>
>
> The general version of this looks like classical PRE.

It's partial dead code elimination, the opposite problem.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/35aeef3e/attachment.html 

From kremenek at apple.com  Wed Oct 14 13:08:59 2009
From: kremenek at apple.com (Ted Kremenek)
Date: Wed, 14 Oct 2009 11:08:59 -0700
Subject: [LLVMdev] new warnings: possible use of uninitialized value?
Message-ID: <A1B599E1-39F2-48DB-8EB1-1835A7310293@apple.com>

I'm seeing the following warning when compiling LLVM trunk in a  
Release build:

  llvm/lib/CodeGen/PrologEpilogInserter.cpp: In member function ?void  
llvm::PEI::scavengeFrameVirtualRegs(llvm::MachineFunction&)?:
  llvm/lib/CodeGen/PrologEpilogInserter.cpp:770: warning: ?PrevValue?  
may be used uninitialized in this function

I briefly looked at the code and it looks like PrevValue is used  
correctly, but there is enough logic here that I'm not familiar with  
that I could easily be mistaken.

From mrs at apple.com  Wed Oct 14 13:09:51 2009
From: mrs at apple.com (Mike Stump)
Date: Wed, 14 Oct 2009 11:09:51 -0700
Subject: [LLVMdev] fudging the top-level Makefile
In-Reply-To: <4C796CBB-C33B-49BA-8B58-EEA4E945F1DA@apple.com>
References: <BC491C5D-521C-493B-BC67-FA1455D0F010@apple.com>
	<A0929213-3743-4093-9337-FE441F24C893@apple.com>
	<2896E598-AED0-49D3-8854-63892F333386@apple.com>
	<E9913FC3-B4C3-4264-8EFF-328E2B4C4CC4@apple.com>
	<4C796CBB-C33B-49BA-8B58-EEA4E945F1DA@apple.com>
Message-ID: <A06187BF-C20D-4054-818F-3268062ED90E@apple.com>

On Oct 14, 2009, at 9:35 AM, Stuart Hastings wrote:
> The alternative is to wrap the entire body of the top-level Makefile  
> in a conditional.  IMHO this is uglier and more fragile than my  
> original proposal, but it's still workable:

Well, that is indeed what I had in mind.  I'll leave it to others as  
to what version they prefer.  I think it is advantageous to leave the  
Makefile in place at the expense of the 6 extra lines.

From baldrick at free.fr  Wed Oct 14 15:03:05 2009
From: baldrick at free.fr (Duncan Sands)
Date: Wed, 14 Oct 2009 22:03:05 +0200
Subject: [LLVMdev] Options in OPT
In-Reply-To: <844oq4bip0.fsf@sauna.l.org>
References: <d17b77a40910120959q2ee1fa16jd65cede7a85f0fae@mail.gmail.com>
	<844oq4bip0.fsf@sauna.l.org>
Message-ID: <4AD62E79.2020104@free.fr>

>> I also try 'opt --help'; but the option is not listed.
> 
> Try opt --help-hidden.

I've changed opt so that the -S option is no longer hidden.

Ciao,

Duncan.

From vgrover528 at gmail.com  Thu Oct 15 01:07:09 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Wed, 14 Oct 2009 23:07:09 -0700
Subject: [LLVMdev] Moving dependent code into conditional statements
In-Reply-To: <CD7A022E-13DF-4614-A89B-1D4B67032557@illinois.edu>
References: <000601ca4c9e$f1861340$d49239c0$@net>
	<66E0F652-87A0-4BCD-90F0-ECAF588B2551@apple.com>
	<CD7A022E-13DF-4614-A89B-1D4B67032557@illinois.edu>
Message-ID: <35657f570910142307y4e5f580bl99b6c61c9e6b1f14@mail.gmail.com>

This is done by partial dead code elimination (PDE), which moves
computations forward without them redundant. This was first reported in PLDI
94 (I think) - the basic version is bit-vector based and is O(n^4) in
complexity. There is no good SSA version that I am aware of - though there
was one which I cant recall at the moment that uses value graphs.
Vinod


On Wed, Oct 14, 2009 at 10:54 AM, Vikram S. Adve <vadve at illinois.edu> wrote:

> On Oct 14, 2009, at 10:22 AM, Chris Lattner wrote:
>
>
> On Oct 14, 2009, at 12:21 AM, Nicolas Capens wrote:
>
> Hi all,
>
> Is there any existing optimization pass that will move as much code into
> the body of a forward branch as possible? Consider the following example:
>
>
> Hi Nicolas,
>
> Instcombine does this in simple cases
>
>
>
> The general version of this looks like classical PRE.
>
> --Vikram
> *Associate Professor, Computer Science*
> *University of Illinois at Urbana-Champaign*
> *http://llvm.org/~vadve*
> *
> *
>
>
> (see "See if we can trivially sink this instruction to a successor basic
> block.") but it misses this case because the if gets folded into a select
> early.  It was also not handling the "phi use" case very aggressively, which
> I fixed in r84103.  We now sink the divide and add in this example:
>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         int y = (x + 1) / x;   // Expensive calculation! Result written to
> memory.
>
>         if(x == 0)   // Forward branch
>         {
> bar();
>             x = y;   // Body
>         }
>     }
>
>     return x;
> }
>
>
> -Chris
>
>
>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         int y = (x + 1) / x;   // Expensive calculation! Result written to
> memory.
>
>         if(x == 0)   // Forward branch
>         {
>             x = y;   // Body
>         }
>     }
>
>     return x;
> }
>
> It appears that LLVM compiles this quite literally, performing the
> expensive calculation a million times. Yet it could be rewritten like this:
>
> int foo(int x)
> {
>     for(int i = 0; i < 1000000; i++)
>     {
>         if(x == 0)   // Unlikely to hit
>         {
>             int y = (x + 1) / x;
>             x = y;
>         }
>     }
>
>     return x;
> }
>
> This runs way faster.
>
> I noticed there?s a loop hoisting optimization (moving as many independent
> operations out of the body of a backward branch), but I?m looking for its
> twin. Did I overlook it or is it not yet supported?
>
> Thanks,
>
> Nicolas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> <ATT00001.txt>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091014/eb4f44ba/attachment.html 

From clattner at apple.com  Thu Oct 15 02:05:46 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 00:05:46 -0700
Subject: [LLVMdev] Developer meeting videos up
Message-ID: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>

Hi All,

All of the videos are now up on the web page, and most of the slides  
are up (still need to get David's and Evan's slides).  Please let me  
know if you hit any problems.

You can access the content here:
http://llvm.org/devmtg/2009-10/

FYI, one room recorded a screencast and the other was recorded with a  
standalone camera.  This means that you can't see the speakers in one  
room, which is unfortunate but much better than no video :).

I want to send a huge thanks to Jason Molenda.  Not only did he  
contribute his equipment to record the event, he also collected a  
tremendous amount of the content, edited the videos, transcoded them  
and did a lot of other great work.  Getting nice videos up takes a lot  
more work than it seems, and the video quality is very high this  
year.  Thank you Jason!

-Chris

From 49640f8a at gmail.com  Thu Oct 15 02:58:30 2009
From: 49640f8a at gmail.com (Martins Mozeiko)
Date: Thu, 15 Oct 2009 10:58:30 +0300
Subject: [LLVMdev] JIT on ARM
In-Reply-To: <9F3A7182-F30F-4AEE-94E1-F110DCBEDE90@apple.com>
References: <D899C6D8-2814-498A-A056-41C3A8175E74@gmail.com>
	<9F3A7182-F30F-4AEE-94E1-F110DCBEDE90@apple.com>
Message-ID: <9EDC8FCF-80C1-4233-84E6-F92907C7760D@gmail.com>

Ok, thanks for answers. I will try to do things you suggested.

--
Martins Mozeiko


On Oct 14, 2009, at 20:27 , Jim Grosbach wrote:

> Forgot to mention. I don't know how well the canadian cross compile  
> stuff works in 2.5. We made some improvements in that area for 2.6.  
> If you have trouble with it, I'd suggest trying 2.6 (or even better,  
> ToT svn) and seeing if things are improved there.
>
>
> -Jim
> On Sep 25, 2009, at 2:04 AM, Martins Mozeiko wrote:
>
>> Hello.
>>
>> My goal is to use LLVM with JIT compiler for ARM on Android device.
>>
>> Currently I have successfully built and executed LLVM bitcode with
>> interpreter on Android. Speed is not so great, that is why I want to
>> use JIT.
>> I tried building bitcode on windows with llvm-gcc that is provided on
>> llvm home page. Resulting bitcode runs great in interpreter, but it
>> doesn't use JIT. From what I understand from LLVM that it is because
>> of target triple or datalayout. On PC in my case target triple is
>> "i386-mingw32", but LLVM JIT for ARM expects something that starts
>> with "armv" or "thumb". Also datalayout differs a lot. If I  
>> understand
>> correctly that is because bitcode actually contains some of platform
>> specific optimizations (like integer endianness), so I can't simply
>> change target triple string and everything will run.
>>
>> What I am now doing, is - I am trying to build gcc from gcc-4.2-
>> llvm-2.5 sources with following configure line in cygwin shell:
>>
>> ../llvm-gcc4.2-2.4.source/configure --enable-languages=c,c++ -- 
>> enable-
>> checking --enable-llvm=$PWD/../llvm-objects --disable-bootstrap --
>> disable-multilib --disable-nls --target=arm-eabi
>>
>> My undertanding is that this will produce llvm-gcc compiler that will
>> output LLVM bitcode with target triple that starts with "arm", so  
>> LLVM
>> will use JIT on it.
>>
>> Currently I am getting compile problems when running make (see  
>> below).
>> Has anyone done something similar and can explain what I am doing
>> wrong, or how should it be done in some other way to get JIT compiler
>> running on ARM?
>>
>>
>> make[2]: Entering directory `/cygdrive/r/android/llvm/llvm-gcc4.2-
>> objects/gcc'
>> gcc   -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-
>> strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-
>> long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-
>> definition -Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -
>> DGENERATOR_FILE  -o build/gengtype.exe \
>>            build/gengtype.o build/gengtype-lex.o build/gengtype-
>> yacc.o build/errors.o ../build-i686-pc-cygwin/libiberty/libiberty.a
>> build/gengtype.o: In function `adjust_field_type':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:763: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:771: undefined reference to
>> `_lexer_line'
>> build/gengtype.o: In function `adjust_field_tree_exp':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:713: undefined reference to
>> `_lexer_line'
>> build/gengtype.o: In function `adjust_field_rtx_def':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:488: undefined reference to
>> `_lexer_line'
>> build/gengtype.o: In function `adjust_field_type':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:785: undefined reference to
>> `_lexer_line'
>> build/gengtype.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
>> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype.c:725: more undefined
>> references to `_lexer_line' follow
>> build/gengtype.o: In function `main':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
>> `_parse_file'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype.c:3070: undefined reference to
>> `_parse_file'
>> build/gengtype-yacc.o: In function `yyparse':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:73: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:75: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:76: undefined reference to
>> `_lexer_toplevel_done'
>> build/gengtype-yacc.o: In function `yyparse':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
>> 1873:
>> undefined reference to `_yyerror'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
>> 1379:
>> undefined reference to `_yylex'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
>> 1877:
>> undefined reference to `_yyerror'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/gengtype-yacc.c: 
>> 1995:
>> undefined reference to `_yyerror'
>> build/gengtype-yacc.o: In function `yyparse':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:122: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:110: undefined reference to
>> `_lexer_toplevel_done'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:102: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:97: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:92: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:239: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:235: undefined reference to
>> `_lexer_line'
>> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
>> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:231: more
>> undefined references to `_lexer_line' follow
>> build/gengtype-yacc.o: In function `yyparse':
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:84: undefined reference to
>> `_lexer_toplevel_done'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:203: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:176: undefined reference to
>> `_lexer_line'
>> /cygdrive/r/android/llvm/llvm-gcc4.2-objects/gcc/../../llvm-
>> gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: undefined reference to
>> `_lexer_line'
>> build/gengtype-yacc.o:/cygdrive/r/android/llvm/llvm-gcc4.2-objects/
>> gcc/../../llvm-gcc4.2-2.4.source/gcc/gengtype-yacc.y:165: more
>> undefined references to `_lexer_line' follow
>> collect2: ld returned 1 exit status
>> make[2]: *** [build/gengtype.exe] Error 1
>>
>> --
>> Martins Mozeiko
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From xuzhongxing at gmail.com  Thu Oct 15 03:07:52 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Thu, 15 Oct 2009 16:07:52 +0800
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <5400aeb80910150107t79c69255u6308c86c6da21f8f@mail.gmail.com>

Thanks! I'm waiting for this.

2009/10/15 Chris Lattner <clattner at apple.com>:
> Hi All,
>
> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides). ?Please let me
> know if you hit any problems.
>
> You can access the content here:
> http://llvm.org/devmtg/2009-10/
>
> FYI, one room recorded a screencast and the other was recorded with a
> standalone camera. ?This means that you can't see the speakers in one
> room, which is unfortunate but much better than no video :).
>
> I want to send a huge thanks to Jason Molenda. ?Not only did he
> contribute his equipment to record the event, he also collected a
> tremendous amount of the content, edited the videos, transcoded them
> and did a lot of other great work. ?Getting nice videos up takes a lot
> more work than it seems, and the video quality is very high this
> year. ?Thank you Jason!
>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From baldrick at free.fr  Thu Oct 15 03:49:19 2009
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 15 Oct 2009 10:49:19 +0200
Subject: [LLVMdev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <4AD6E20F.2030301@free.fr>

> I want to send a huge thanks to Jason Molenda.  Not only did he  
> contribute his equipment to record the event, he also collected a  
> tremendous amount of the content, edited the videos, transcoded them  
> and did a lot of other great work.  Getting nice videos up takes a lot  
> more work than it seems, and the video quality is very high this  
> year.  Thank you Jason!

And his equipment actually worked, unlike some of the in-house gear!

Ciao,

Duncan.

From tianwei.sheng at gmail.com  Thu Oct 15 08:10:09 2009
From: tianwei.sheng at gmail.com (Tianwei)
Date: Thu, 15 Oct 2009 21:10:09 +0800
Subject: [LLVMdev] strace for whole-program bitcodes (was: RE: building
	whole-program bitcode with LLVM)
In-Reply-To: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
References: <AcoM1MKxb8yPr6QtR9StmpV2h2bO5QFb7zRwDYgI22A=>
	<14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
Message-ID: <7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com>

Hi, Kelly,   Have you found the solution for this problem? I met a similar
problem when I were trying to test MySQL 5.0 with LLVM. The following is my
step, but still failed since llvm-ld can not recognize some gcc link flags.
1. during the configuration, use a script such as llvm-gcc.sh, at this time
the script only invoke the gcc. This is necessary because the gnu configure
will test the compiler before configuration.
2. for configuration, specify CC and CXX as llvm-gcc.sh and llvm-g++.sh,
also pass a special LDFLAG.
3. after configuration, rewrite the llvm-gcc.sh and llvm-g++.sh to parse the
LDFLAGS to determine if we should use
"llvm-gcc --emit-llvm " or "llvm-ld"
4. but finally, I still met the following error:
 libtool: link: mycc.sh -g -DDBUG_ON -DSAFE_MUTEX -O0 -g3 -shit-shit
-rdynamic -o comp_sql comp_sql.o  -lpthread -lcrypt -lnsl -lm -lpthread

                                llvm-ld: Unknown command line argument '-g'.
 Try: 'llvm-ld --help'

llvm-ld: Unknown command line argument '-DDBUG_ON'.  Try: 'llvm-ld --help'

llvm-ld: Unknown command line argument '-DSAFE_MUTEX'.  Try: 'llvm-ld
--help'
llvm-ld: Unknown command line argument '-O0'.  Try: 'llvm-ld --help'

llvm-ld: Unknown command line argument '-g3'.  Try: 'llvm-ld --help'

llvm-ld: Unknown command line argument '-rdynamic'.  Try: 'llvm-ld --help'

someone suggested me to use gold-plugin, I know nothing about it yet, I will
have a try later.  Does anyone have a good solution for this problem?

Thanks.

Tianwei

On Fri, Oct 9, 2009 at 6:26 AM, Kelly, Terence P (HP Labs Researcher) <
terence.p.kelly at hp.com> wrote:

>
> Hi,
>
> It would be nice if it were easier for relative
> novices to build whole-program bitcodes for
> large, complex applications with hairy build
> systems.  Several readers of this list have
> been trying various approaches for a few months
> but as far as I know we haven't yet found a
> good general solution.  Approaches that have
> been tried include 1) placing wrappers for the
> usual tools (gcc, ar, as, ld, etc.) first on
> the $PATH, and having the wrappers pass the
> buck to the LLVM equivalent tools after cleaning
> up the arguments; and 2) using the Gold plugin.
>
> Recently another possibility occurred to me,
> and I'm wondering if anyone has tried it.
> The basic idea goes like this:  A) use the
> "strace" utility to trace the default build
> system and log all invocations of all tools;
> B) extract from the log a build recipe in the
> form of tool invocations, with the default
> tools replaced by LLVM equivalents.
>
> I started thinking along these lines after
> finding some genuine madness in a build system
> (it used AWK to munge together existing .c files
> into new ones midway through the build).  I want
> a method that's guaranteed to mimic faithfully
> an arbitrarily nutty default build system, and
> an strace-based approach seemed like a "Gordian
> knot" solution.  However I haven't tried it yet
> and I'm wondering if anyone else has, or if
> anyone can think of situations where it will
> fail.
>
> Thanks!
>
> -- Terence
>
> > -----Original Message-----
> > From: Kelly, Terence P (HP Labs Researcher)
> > Sent: Friday, July 31, 2009 6:12 PM
> > To: 'llvmdev at cs.uiuc.edu'
> > Cc: 'Vikram S. Adve'
> > Subject: building whole-program bitcode with LLVM
> >
> >
> > Hi,
> >
> > Professor Adve suggested that we post this question to llvm-dev.
> > Thanks in advance for your advice.
> >
> > My colleagues and I want to create whole-program bitcode for large
> > real programs like Apache, BIND, OpenLDAP, etc.  We want the
> > whole-program bitcode to include every part of the program for which
> > we have source code.  For example, in the case of Apache's "httpd"
> > server, we want to create a whole-program bitcode file "httpd.bc"
> > containing functions that the default build system stashes in various
> > application-specific auxiliary libraries (e.g., Apache's libapr and
> > libaprutil).
> >
> > Our motive is *not* link-time optimization; we're interested in
> > analyzing and modifying the whole-program bitcode in other ways.
> > Once we have created a whole-program bitcode, we want to compile it
> > to native assembly, then pass it thru the native assembler & linker
> > to obtain a native executable whose behavior (except for performance)
> > is identical to that of an executable obtained from the default build
> > system.  We do *not* want standard libraries like libc and libpthread
> > to be incorporated as bitcode in the whole-program bitcode; they can
> > be linked in at the final step, after we have converted the
> > whole-program bitcode to native assembly and assembled & linked it.
> >
> > We have been able to achieve our goal for small programs consisting
> > of a handful of translation units, so we know that our goal is
> > attainable in principle.  Problems start when we tackle big programs
> > with complex build systems.  We want to find a generic strategy that
> > works with most real world open source C/C++ programs without too
> > much fuss, because we want to use it on at least a dozen different
> > programs.  Ideally we want a strategy that works with unmodified
> > default build systems, because eventually we hope to produce a tool
> > that is easy for other developers to use.
> >
> > Initially we had hoped simply to replace gcc, as, ld, etc. with their
> > LLVM counterparts in the standard build systems, but we haven't been
> > able to make that strategy work.  Several different approaches along
> > these lines fail in various ways.  Some have recommended the Gold
> > plugin, but it's not clear from the documentation that it does what
> > we want, and we haven't been successful in installing it yet.
> >
> > Does anyone have experience in constructing whole-program bitcodes
> > that include app-specific libraries for large open-source programs?
> > If you could share the right tricks, that would be very helpful.
> >
> > Thanks!
> >
> > -- Terence Kelly, HP Labs
> >
> > ________________________________
> >
> > From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu]
> > Sent: Friday, July 24, 2009 8:05 PM
> > To: Kelly, Terence P (HP Labs Researcher)
> > Cc: Swarup Sahoo
> > Subject: Re: building complex software with LLVM
> >
> > Hi Terence,
> >
> > ...
> >
> > I also recommend sending any such technical
> > questions about LLVM to llvmdev at cs.uiuc.edu.
> > There are a large number of active (and very
> > helpful) LLVM users on that list.  Replies
> > go to the list so you should join the list
> > to see them.
> >
> > Good luck!
> >
> > --Vikram
> > Associate Professor, Computer Science
> > University of Illinois at Urbana-Champaign
> > http://llvm.org/~vadve
> >
> >
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Sheng, Tianwei
Inst. of High Performance Computing
Dept. of Computer Sci. & Tech.
Tsinghua Univ.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091015/1f1b42f3/attachment-0001.html 

From timo.lindfors at iki.fi  Thu Oct 15 09:14:35 2009
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Thu, 15 Oct 2009 17:14:35 +0300
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com>
	(tianwei.sheng@gmail.com's message of "Thu, 15 Oct 2009 21:10:09
	+0800")
References: <AcoM1MKxb8yPr6QtR9StmpV2h2bO5QFb7zRwDYgI22A=>
	<14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
	<7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com>
Message-ID: <84tyy0922c.fsf@sauna.l.org>

Tianwei <tianwei.sheng at gmail.com> writes:
> someone suggested me to use gold-plugin, I know nothing about it yet, I will
> have a try later.  Does anyone have a good solution for this problem?

Afaik gold does not help here. I tried it and managed to only generate
native code.

I'm currently investigating an alternative approach to produce
whole-program bitcodes:

1) add /tmp/wrap to PATH
2) create /tmp/wrap/gcc with the following contents

#!/bin/sh
exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@"

3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs
4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1
5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real
   ld and does not pass any unknown flags to it.

With this approach I was able to compile and run airstrike (a 2d
dogfighting game) in bitcode form very transparently with:

$ make-bitcode fakeroot apt-get --build source airstrike
$ sudo dpkg -i airstrike*.deb
$ airstrike

If you are interested I can try to rework my scripts to a shape where
they could be used by somebody else.

(*) I am not actually calling llvm-ld directly. Instead I have an
    "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to
    pack the resulting bitcode to a shell script that can execute itself with
    lli and use the correct -load options.

From stefanus.du.toit at intel.com  Thu Oct 15 09:41:05 2009
From: stefanus.du.toit at intel.com (Du Toit, Stefanus)
Date: Thu, 15 Oct 2009 08:41:05 -0600
Subject: [LLVMdev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <2C2ECF4B05BCF3489866AB805260FEC504CE39F383@rrsmsx509.amr.corp.intel.com>

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> Sent: Thursday, October 15, 2009 3:06 AM
> To: LLVM Developers Mailing List; clang-dev Developers
> Cc: Jason Molenda
> Subject: [LLVMdev] Developer meeting videos up
> 
> Hi All,
> 
> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides).  Please let me
> know if you hit any problems.

This is great, thanks!

> 
> You can access the content here:
> http://llvm.org/devmtg/2009-10/

I noticed there's nothing up for Dan's talk on ScalarEvolution, nor for Lang's on RA. Are these still going to be posted?

Stefanus


From daniel at zuster.org  Thu Oct 15 10:12:53 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 15 Oct 2009 08:12:53 -0700
Subject: [LLVMdev] strace for whole-program bitcodes (was: RE: building
	whole-program bitcode with LLVM)
In-Reply-To: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
References: <AcoM1MKxb8yPr6QtR9StmpV2h2bO5QFb7zRwDYgI22A=>
	<14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
Message-ID: <6a8523d60910150812q77ae1687ndae70a84f9f8d926@mail.gmail.com>

Hi Terence,

I believe that this is in fact similar to an approach Coverity uses
(or used at one time) as a robust solution to determine what was done
during a build. I can imagine that one can build a robust system
following this technique, but it also seems like it might be quite a
bit of work.

Another possible alternative not mentioned is to teach the compiler
driver (clang, most likely) to understand how to deal with bitcode
files on platforms with no LLVM linker support. This isn't terribly
difficult, and would work as long as all access to the tools was done
through the driver (e.g., CC). There might still be problems with
build systems that call tools like ar/ld directly.

 - Daniel

On Thu, Oct 8, 2009 at 3:26 PM, Kelly, Terence P (HP Labs Researcher)
<terence.p.kelly at hp.com> wrote:
>
> Hi,
>
> It would be nice if it were easier for relative
> novices to build whole-program bitcodes for
> large, complex applications with hairy build
> systems. ?Several readers of this list have
> been trying various approaches for a few months
> but as far as I know we haven't yet found a
> good general solution. ?Approaches that have
> been tried include 1) placing wrappers for the
> usual tools (gcc, ar, as, ld, etc.) first on
> the $PATH, and having the wrappers pass the
> buck to the LLVM equivalent tools after cleaning
> up the arguments; and 2) using the Gold plugin.
>
> Recently another possibility occurred to me,
> and I'm wondering if anyone has tried it.
> The basic idea goes like this: ?A) use the
> "strace" utility to trace the default build
> system and log all invocations of all tools;
> B) extract from the log a build recipe in the
> form of tool invocations, with the default
> tools replaced by LLVM equivalents.
>
> I started thinking along these lines after
> finding some genuine madness in a build system
> (it used AWK to munge together existing .c files
> into new ones midway through the build). ?I want
> a method that's guaranteed to mimic faithfully
> an arbitrarily nutty default build system, and
> an strace-based approach seemed like a "Gordian
> knot" solution. ?However I haven't tried it yet
> and I'm wondering if anyone else has, or if
> anyone can think of situations where it will
> fail.
>
> Thanks!
>
> -- Terence
>
>> -----Original Message-----
>> From: Kelly, Terence P (HP Labs Researcher)
>> Sent: Friday, July 31, 2009 6:12 PM
>> To: 'llvmdev at cs.uiuc.edu'
>> Cc: 'Vikram S. Adve'
>> Subject: building whole-program bitcode with LLVM
>>
>>
>> Hi,
>>
>> Professor Adve suggested that we post this question to llvm-dev.
>> Thanks in advance for your advice.
>>
>> My colleagues and I want to create whole-program bitcode for large
>> real programs like Apache, BIND, OpenLDAP, etc. ?We want the
>> whole-program bitcode to include every part of the program for which
>> we have source code. ?For example, in the case of Apache's "httpd"
>> server, we want to create a whole-program bitcode file "httpd.bc"
>> containing functions that the default build system stashes in various
>> application-specific auxiliary libraries (e.g., Apache's libapr and
>> libaprutil).
>>
>> Our motive is *not* link-time optimization; we're interested in
>> analyzing and modifying the whole-program bitcode in other ways.
>> Once we have created a whole-program bitcode, we want to compile it
>> to native assembly, then pass it thru the native assembler & linker
>> to obtain a native executable whose behavior (except for performance)
>> is identical to that of an executable obtained from the default build
>> system. ?We do *not* want standard libraries like libc and libpthread
>> to be incorporated as bitcode in the whole-program bitcode; they can
>> be linked in at the final step, after we have converted the
>> whole-program bitcode to native assembly and assembled & linked it.
>>
>> We have been able to achieve our goal for small programs consisting
>> of a handful of translation units, so we know that our goal is
>> attainable in principle. ?Problems start when we tackle big programs
>> with complex build systems. ?We want to find a generic strategy that
>> works with most real world open source C/C++ programs without too
>> much fuss, because we want to use it on at least a dozen different
>> programs. ?Ideally we want a strategy that works with unmodified
>> default build systems, because eventually we hope to produce a tool
>> that is easy for other developers to use.
>>
>> Initially we had hoped simply to replace gcc, as, ld, etc. with their
>> LLVM counterparts in the standard build systems, but we haven't been
>> able to make that strategy work. ?Several different approaches along
>> these lines fail in various ways. ?Some have recommended the Gold
>> plugin, but it's not clear from the documentation that it does what
>> we want, and we haven't been successful in installing it yet.
>>
>> Does anyone have experience in constructing whole-program bitcodes
>> that include app-specific libraries for large open-source programs?
>> If you could share the right tricks, that would be very helpful.
>>
>> Thanks!
>>
>> -- Terence Kelly, HP Labs
>>
>> ________________________________
>>
>> From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu]
>> Sent: Friday, July 24, 2009 8:05 PM
>> To: Kelly, Terence P (HP Labs Researcher)
>> Cc: Swarup Sahoo
>> Subject: Re: building complex software with LLVM
>>
>> Hi Terence,
>>
>> ...
>>
>> I also recommend sending any such technical
>> questions about LLVM to llvmdev at cs.uiuc.edu.
>> There are a large number of active (and very
>> helpful) LLVM users on that list. ?Replies
>> go to the list so you should join the list
>> to see them.
>>
>> Good luck!
>>
>> --Vikram
>> Associate Professor, Computer Science
>> University of Illinois at Urbana-Champaign
>> http://llvm.org/~vadve
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From daniel at zuster.org  Thu Oct 15 10:17:00 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 15 Oct 2009 08:17:00 -0700
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <84tyy0922c.fsf@sauna.l.org>
References: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
	<7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com>
	<84tyy0922c.fsf@sauna.l.org>
Message-ID: <6a8523d60910150817x20b10e68l1434baad2e868b28@mail.gmail.com>

On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors
<timo.lindfors at iki.fi> wrote:
> Tianwei <tianwei.sheng at gmail.com> writes:
>> someone suggested me to use gold-plugin, I know nothing about it yet, I will
>> have a try later. ?Does anyone have a good solution for this problem?
>
> Afaik gold does not help here. I tried it and managed to only generate
> native code.

"Just" gold isn't quite good enough, because at the last final link
steps gold will still generate native code. However, it should be
possible to find a way to get gold to leave the merged bitcode around
somewhere, or perhaps do something like llvm-ld. Nicholas?

The advantage of this approach is that it will potentially work with
build systems that call ar/ld directly.

> I'm currently investigating an alternative approach to produce
> whole-program bitcodes:
>
> 1) add /tmp/wrap to PATH
> 2) create /tmp/wrap/gcc with the following contents
>
> #!/bin/sh
> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@"
>
> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs
> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1
> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real
> ? ld and does not pass any unknown flags to it.
>
> With this approach I was able to compile and run airstrike (a 2d
> dogfighting game) in bitcode form very transparently with:
>
> $ make-bitcode fakeroot apt-get --build source airstrike
> $ sudo dpkg -i airstrike*.deb
> $ airstrike

Very clever though. :)

 - Daniel

> If you are interested I can try to rework my scripts to a shape where
> they could be used by somebody else.
>
> (*) I am not actually calling llvm-ld directly. Instead I have an
> ? ?"llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to
> ? ?pack the resulting bitcode to a shell script that can execute itself with
> ? ?lli and use the correct -load options.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From anton at korobeynikov.info  Thu Oct 15 10:29:00 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Thu, 15 Oct 2009 19:29:00 +0400
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>

Hi, Chris

> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides). ?Please let me
> know if you hit any problems.
First of all, thanks a lot about all stuff with videos & slides posting.

I'm a bit curious: is there any reason why are other slides / videos
not available (it seems that the ones missing are from Apple folks)?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University


From clattner at apple.com  Thu Oct 15 10:45:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 08:45:07 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
Message-ID: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>

On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
> Hi, Chris
>
>> All of the videos are now up on the web page, and most of the slides
>> are up (still need to get David's and Evan's slides).  Please let me
>> know if you hit any problems.
> First of all, thanks a lot about all stuff with videos & slides  
> posting.
>
> I'm a bit curious: is there any reason why are other slides / videos
> not available (it seems that the ones missing are from Apple folks)?

Unfortunately, we found out at the last minute that Apple has a rule  
which prevents its engineers from giving video taped talks or  
distributing slides.  We will hold onto the video and slide assets in  
case this rule changes in the future.

-Chris

From stefanus.du.toit at intel.com  Thu Oct 15 11:34:23 2009
From: stefanus.du.toit at intel.com (Du Toit, Stefanus)
Date: Thu, 15 Oct 2009 10:34:23 -0600
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <2C2ECF4B05BCF3489866AB805260FEC504CE39F3A0@rrsmsx509.amr.corp.intel.com>

Hi Chris,

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Chris Lattner
> Sent: Thursday, October 15, 2009 11:45 AM
> To: Anton Korobeynikov
> Cc: clang-dev Developers; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] [cfe-dev] Developer meeting videos up
> 
> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.

That's really too bad. Due to a meeting conflict I was unable to attend Dan's talk on ScalarEvolution, but it was one of the ones I was most interested in seeing given our interest in loop optimization. I also missed the beginning of Lang's talk on future register allocation work, which we also have a keen interest in. I expect a lot of people would be very interested in Nate's OpenCL talk as well, given the current interest in OpenCL and that it's a nice real-world example of LLVM usage.

It would be great if an exception could be made for these somehow. I know there are others interested in seeing them as well who were unable to attend the meeting in person.

Thanks,

Stefanus

--
Stefanus Du Toit <stefanus.du.toit at intel.com>
  Intel PPL/DPD/SSG
  phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463



From dkeppler at mitre.org  Thu Oct 15 13:30:59 2009
From: dkeppler at mitre.org (Keppler, Dave)
Date: Thu, 15 Oct 2009 14:30:59 -0400
Subject: [LLVMdev] [Fwd: Re:  strace for whole-program bitcodes]
In-Reply-To: <4AD76184.4050000@kepps.net>
References: <4AD76184.4050000@kepps.net>
Message-ID: <600C0C33850FFE49B76BDD81AED4D2580132080E32@IMCMBX3.MITRE.ORG>

>>> someone suggested me to use gold-plugin, I know nothing about it yet, I
>will
>>> have a try later.  Does anyone have a good solution for this problem?
>>
>> Afaik gold does not help here. I tried it and managed to only generate
>> native code.
>
>"Just" gold isn't quite good enough, because at the last final link
>steps gold will still generate native code. However, it should be
>possible to find a way to get gold to leave the merged bitcode around
>somewhere, or perhaps do something like llvm-ld. Nicholas?
>

I've had some success by adding a call to lto_codegen_write_merged_modules(cg, somePath) at the end of the gold plugin's all_symbols_read_hook() function just before it calls lto_codegen_dispose(cg).  The somePath is set via a plugin option which I patched llvm-gcc to pass through as a derivation from its -o argument.

It has worked on several mid-complexity applications I've tried so far (lighttpd, wu-ftpd, tcdump, and the sqlite library).

I would be interested in seeing more of Timo's solution.  My goal is to eventually have a way to get bitcode + lli script outputs for off the shelf applications without modifying their make files.

>The advantage of this approach is that it will potentially work with
>build systems that call ar/ld directly.
>


From shiyao at gmail.com  Thu Oct 15 16:33:08 2009
From: shiyao at gmail.com (SHI, Yao)
Date: Fri, 16 Oct 2009 05:33:08 +0800
Subject: [LLVMdev] Using LLVM to build large projects
Message-ID: <683f73640910151433v5524c307l1f151d89ec5e18eb@mail.gmail.com>

Hi @ll,

I am using LLVM to build MySQL. It's OK when I use llvmc/llvm-gcc/llvm-g++
instead of gcc.
However, such processing disabled interprocedural analysis that has to
combine all bitcode files.

My question is how to build MySQL with interprocedural analysis? I really
don't like editing all Makefiles one by one. Is there any convenient
approach?

Thank you.




Yao Shi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/91fe7330/attachment.html 

From espindola at google.com  Thu Oct 15 17:04:56 2009
From: espindola at google.com (Rafael Espindola)
Date: Thu, 15 Oct 2009 18:04:56 -0400
Subject: [LLVMdev] Using LLVM to build large projects
In-Reply-To: <683f73640910151433v5524c307l1f151d89ec5e18eb@mail.gmail.com>
References: <683f73640910151433v5524c307l1f151d89ec5e18eb@mail.gmail.com>
Message-ID: <38a0d8450910151504w580586f3jb9e119a2a6680356@mail.gmail.com>

2009/10/15 SHI, Yao <shiyao at gmail.com>:
> Hi @ll,
>
> I am using LLVM to build MySQL. It's OK when I use llvmc/llvm-gcc/llvm-g++
> instead of gcc.
> However, such processing disabled interprocedural analysis that has to
> combine all bitcode files.
>
> My question is how to build MySQL with interprocedural analysis? I really
> don't like editing all Makefiles one by one. Is there any convenient
> approach?

On OS X I think you can just use -O4. On Linux you can use the gold
linker with a plugin to accept llvm IL:

http://llvm.org/docs/GoldPlugin.html

> Thank you.
>
>
>
>
> Yao Shi
>

Cheers,
-- 
Rafael ?vila de Esp?ndola


From terence.p.kelly at hp.com  Thu Oct 15 18:52:33 2009
From: terence.p.kelly at hp.com (Kelly, Terence P (HP Labs Researcher))
Date: Thu, 15 Oct 2009 23:52:33 +0000
Subject: [LLVMdev] strace for whole-program bitcodes (was: RE: building
 whole-program bitcode with LLVM)
In-Reply-To: <6a8523d60910150812q77ae1687ndae70a84f9f8d926@mail.gmail.com>
References: <AcoM1MKxb8yPr6QtR9StmpV2h2bO5QFb7zRwDYgI22A=>
	<14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>
	<6a8523d60910150812q77ae1687ndae70a84f9f8d926@mail.gmail.com>
Message-ID: <14ECB8FC41FFF347BB6B26A9E828C2BD303E4C54EF@GVW0432EXB.americas.hpqcorp.net>


Hi Daniel,

Thanks for your reply.

Do we know if the LLVM developers intend to
address this problem in a comprehensive way?
The existing LLVM tools are not quite drop-in
replacements for their standard GCC counterparts;
that's the source of the problems that various
people have encountered when trying to develop
a fully general way to get whole-program bitcodes.

If the LLVM tools *were* fully compatible, I
think that would remove an impediment to much
wider usage of LLVM.  Is full compatibility a
goal for the LLVM developers?

-- Terence

> -----Original Message-----
> From: daniel.dunbar at gmail.com 
> [mailto:daniel.dunbar at gmail.com] On Behalf Of Daniel Dunbar
> Sent: Thursday, October 15, 2009 8:13 AM
> To: Kelly, Terence P (HP Labs Researcher)
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] strace for whole-program bitcodes 
> (was: RE: building whole-program bitcode with LLVM)
> 
> Hi Terence,
> 
> I believe that this is in fact similar to an approach Coverity uses
> (or used at one time) as a robust solution to determine what was done
> during a build. I can imagine that one can build a robust system
> following this technique, but it also seems like it might be quite a
> bit of work.
> 
> Another possible alternative not mentioned is to teach the compiler
> driver (clang, most likely) to understand how to deal with bitcode
> files on platforms with no LLVM linker support. This isn't terribly
> difficult, and would work as long as all access to the tools was done
> through the driver (e.g., CC). There might still be problems with
> build systems that call tools like ar/ld directly.
> 
>  - Daniel
> 
> On Thu, Oct 8, 2009 at 3:26 PM, Kelly, Terence P (HP Labs Researcher)
> <terence.p.kelly at hp.com> wrote:
> >
> > Hi,
> >
> > It would be nice if it were easier for relative
> > novices to build whole-program bitcodes for
> > large, complex applications with hairy build
> > systems. ?Several readers of this list have
> > been trying various approaches for a few months
> > but as far as I know we haven't yet found a
> > good general solution. ?Approaches that have
> > been tried include 1) placing wrappers for the
> > usual tools (gcc, ar, as, ld, etc.) first on
> > the $PATH, and having the wrappers pass the
> > buck to the LLVM equivalent tools after cleaning
> > up the arguments; and 2) using the Gold plugin.
> >
> > Recently another possibility occurred to me,
> > and I'm wondering if anyone has tried it.
> > The basic idea goes like this: ?A) use the
> > "strace" utility to trace the default build
> > system and log all invocations of all tools;
> > B) extract from the log a build recipe in the
> > form of tool invocations, with the default
> > tools replaced by LLVM equivalents.
> >
> > I started thinking along these lines after
> > finding some genuine madness in a build system
> > (it used AWK to munge together existing .c files
> > into new ones midway through the build). ?I want
> > a method that's guaranteed to mimic faithfully
> > an arbitrarily nutty default build system, and
> > an strace-based approach seemed like a "Gordian
> > knot" solution. ?However I haven't tried it yet
> > and I'm wondering if anyone else has, or if
> > anyone can think of situations where it will
> > fail.
> >
> > Thanks!
> >
> > -- Terence
> >
> >> -----Original Message-----
> >> From: Kelly, Terence P (HP Labs Researcher)
> >> Sent: Friday, July 31, 2009 6:12 PM
> >> To: 'llvmdev at cs.uiuc.edu'
> >> Cc: 'Vikram S. Adve'
> >> Subject: building whole-program bitcode with LLVM
> >>
> >>
> >> Hi,
> >>
> >> Professor Adve suggested that we post this question to llvm-dev.
> >> Thanks in advance for your advice.
> >>
> >> My colleagues and I want to create whole-program bitcode for large
> >> real programs like Apache, BIND, OpenLDAP, etc. ?We want the
> >> whole-program bitcode to include every part of the program 
> for which
> >> we have source code. ?For example, in the case of Apache's "httpd"
> >> server, we want to create a whole-program bitcode file "httpd.bc"
> >> containing functions that the default build system stashes 
> in various
> >> application-specific auxiliary libraries (e.g., Apache's libapr and
> >> libaprutil).
> >>
> >> Our motive is *not* link-time optimization; we're interested in
> >> analyzing and modifying the whole-program bitcode in other ways.
> >> Once we have created a whole-program bitcode, we want to compile it
> >> to native assembly, then pass it thru the native assembler & linker
> >> to obtain a native executable whose behavior (except for 
> performance)
> >> is identical to that of an executable obtained from the 
> default build
> >> system. ?We do *not* want standard libraries like libc and 
> libpthread
> >> to be incorporated as bitcode in the whole-program 
> bitcode; they can
> >> be linked in at the final step, after we have converted the
> >> whole-program bitcode to native assembly and assembled & linked it.
> >>
> >> We have been able to achieve our goal for small programs consisting
> >> of a handful of translation units, so we know that our goal is
> >> attainable in principle. ?Problems start when we tackle 
> big programs
> >> with complex build systems. ?We want to find a generic 
> strategy that
> >> works with most real world open source C/C++ programs without too
> >> much fuss, because we want to use it on at least a dozen different
> >> programs. ?Ideally we want a strategy that works with unmodified
> >> default build systems, because eventually we hope to produce a tool
> >> that is easy for other developers to use.
> >>
> >> Initially we had hoped simply to replace gcc, as, ld, etc. 
> with their
> >> LLVM counterparts in the standard build systems, but we 
> haven't been
> >> able to make that strategy work. ?Several different 
> approaches along
> >> these lines fail in various ways. ?Some have recommended the Gold
> >> plugin, but it's not clear from the documentation that it does what
> >> we want, and we haven't been successful in installing it yet.
> >>
> >> Does anyone have experience in constructing whole-program bitcodes
> >> that include app-specific libraries for large open-source programs?
> >> If you could share the right tricks, that would be very helpful.
> >>
> >> Thanks!
> >>
> >> -- Terence Kelly, HP Labs
> >>
> >> ________________________________
> >>
> >> From: Vikram S. Adve [mailto:vadve at cs.uiuc.edu]
> >> Sent: Friday, July 24, 2009 8:05 PM
> >> To: Kelly, Terence P (HP Labs Researcher)
> >> Cc: Swarup Sahoo
> >> Subject: Re: building complex software with LLVM
> >>
> >> Hi Terence,
> >>
> >> ...
> >>
> >> I also recommend sending any such technical
> >> questions about LLVM to llvmdev at cs.uiuc.edu.
> >> There are a large number of active (and very
> >> helpful) LLVM users on that list. ?Replies
> >> go to the list so you should join the list
> >> to see them.
> >>
> >> Good luck!
> >>
> >> --Vikram
> >> Associate Professor, Computer Science
> >> University of Illinois at Urbana-Champaign
> >> http://llvm.org/~vadve
> >>
> >>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> 

From plmdvy at gmail.com  Thu Oct 15 19:45:44 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Fri, 16 Oct 2009 00:45:44 +0000
Subject: [LLVMdev] Haiku Triple support
Message-ID: <9430ad070910151745v251c4c84j66c829576dcaf3fa@mail.gmail.com>

support for triple in haiku

it touches lib/Support/Triple.cpp
and include/llvm/ADT/Triple.h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/049eccbe/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haikutriple.patch
Type: application/octet-stream
Size: 2558 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/049eccbe/attachment.obj 

From plmdvy at gmail.com  Thu Oct 15 20:01:14 2009
From: plmdvy at gmail.com (Paul Davey)
Date: Fri, 16 Oct 2009 01:01:14 +0000
Subject: [LLVMdev] Haiku Triple support
In-Reply-To: <9430ad070910151745v251c4c84j66c829576dcaf3fa@mail.gmail.com>
References: <9430ad070910151745v251c4c84j66c829576dcaf3fa@mail.gmail.com>
Message-ID: <9430ad070910151801y513f53c7i2c6a9698026bd33b@mail.gmail.com>

Greatest appologies that had some cruft in it, let me send the cleaned one

On Fri, Oct 16, 2009 at 12:45 AM, Paul Davey <plmdvy at gmail.com> wrote:

> support for triple in haiku
>
> it touches lib/Support/Triple.cpp
> and include/llvm/ADT/Triple.h
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/f2635907/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: haikutriple.patch
Type: application/octet-stream
Size: 819 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/f2635907/attachment.obj 

From daniel at zuster.org  Thu Oct 15 20:09:48 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Thu, 15 Oct 2009 18:09:48 -0700
Subject: [LLVMdev] Command Line Bugzilla
Message-ID: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>

Hi all,

Thought this might be of general interest, I hacked up the pybugz tool
to work with llvm.org. It's here if you want it:
  http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz

Unpack somewhere, and make a link to the 'bugz' script. Usage:
--
ddunbar at ozzy-2:~$ bugz get 1000
 * Using http://llvm.org/bugs/
 * Getting bug 1000 ..
Title       : Chris Is Buggy
Assignee    : tonic at nondot.org
...

ddunbar at ozzy-2:~$ bugz search foo
 * Using http://llvm.org/bugs/
 * Searching for 'foo'
   3053 unassignedclangbugs  clang doesn't check foo(int a[static 10]) callers
   3984 unassignedclangbugs  [driver] clang foo.c -std=c++98 doesn't treat inpu
   4120 unassignedclangbugs  better error recovery for digraph confusion: <::fo
   4519 kremenek             [[[[Foo alloc] init] bar] release] marked as Bad r
   4941 unassignedclangbugs  clang-cc should support -fno-builtin-foo
--

Various parameters are probably hard coded to my usage, use at your
own risk. I usually don't create bugs with it, just search and fetch.

I find its much nicer for searching bugzilla, in particular.

 - Daniel

From evan.cheng at apple.com  Thu Oct 15 20:15:19 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Thu, 15 Oct 2009 18:15:19 -0700
Subject: [LLVMdev] What are addSimpleCodeEmitter for?
Message-ID: <8B7093E8-F7FA-472C-AF1E-31398A52FB0B@apple.com>

I forgot. Why do we have LLVMTargetMachine::addSimpleCodeEmitter() when we already have addCodeEmitter()?

Thanks,

Evan

From clattner at apple.com  Thu Oct 15 21:06:42 2009
From: clattner at apple.com (Chris Lattner)
Date: Thu, 15 Oct 2009 19:06:42 -0700
Subject: [LLVMdev] Haiku Triple support
In-Reply-To: <9430ad070910151801y513f53c7i2c6a9698026bd33b@mail.gmail.com>
References: <9430ad070910151745v251c4c84j66c829576dcaf3fa@mail.gmail.com>
	<9430ad070910151801y513f53c7i2c6a9698026bd33b@mail.gmail.com>
Message-ID: <289EF75A-56B3-4050-8BC5-E798D3D55B9E@apple.com>

Thanks, applied in r84238!

On Oct 15, 2009, at 6:01 PM, Paul Davey wrote:

>
> Greatest appologies that had some cruft in it, let me send the  
> cleaned one
>
> On Fri, Oct 16, 2009 at 12:45 AM, Paul Davey <plmdvy at gmail.com> wrote:
> support for triple in haiku
>
> it touches lib/Support/Triple.cpp
> and include/llvm/ADT/Triple.h
>
>
>
> <haikutriple.patch>_______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091015/c2350da5/attachment.html 

From nicholas at mxc.ca  Thu Oct 15 22:38:58 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Thu, 15 Oct 2009 20:38:58 -0700
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <6a8523d60910150817x20b10e68l1434baad2e868b28@mail.gmail.com>
References: <14ECB8FC41FFF347BB6B26A9E828C2BD303D7CBC58@GVW0432EXB.americas.hpqcorp.net>	
	<7618fe50910150610n7a8972b3o83024d330c5fc734@mail.gmail.com>	
	<84tyy0922c.fsf@sauna.l.org>
	<6a8523d60910150817x20b10e68l1434baad2e868b28@mail.gmail.com>
Message-ID: <4AD7EAD2.2000008@mxc.ca>

Daniel Dunbar wrote:
> On Thu, Oct 15, 2009 at 7:14 AM, Timo Juhani Lindfors
> <timo.lindfors at iki.fi> wrote:
>> Tianwei <tianwei.sheng at gmail.com> writes:
>>> someone suggested me to use gold-plugin, I know nothing about it yet, I will
>>> have a try later.  Does anyone have a good solution for this problem?
>> Afaik gold does not help here. I tried it and managed to only generate
>> native code.
> 
> "Just" gold isn't quite good enough, because at the last final link
> steps gold will still generate native code. However, it should be
> possible to find a way to get gold to leave the merged bitcode around
> somewhere, or perhaps do something like llvm-ld. Nicholas?

It's easy. In gold-plugin.cpp all_symbols_read_hook() where 
lto_codegen_compile(cg, ...) is currently called, call 
lto_codegen_write_merged_modules(cg, "/path/to/output.bc") instead.

If someone were to rig this up to a command-line flag (search for 
LDPT_OPTION in the same file) then I would like to commit that change.

Nick

> The advantage of this approach is that it will potentially work with
> build systems that call ar/ld directly.
> 
>> I'm currently investigating an alternative approach to produce
>> whole-program bitcodes:
>>
>> 1) add /tmp/wrap to PATH
>> 2) create /tmp/wrap/gcc with the following contents
>>
>> #!/bin/sh
>> exec llvm-gcc -specs /tmp/wrap/gcc.specs "$@"
>>
>> 3) llvm-gcc -dumpspecs > /tmp/wrap/gcc.specs
>> 4) modify /tmp/wrap/gcc.specs so that it always passes -emit-llvm to cc1
>> 5) modify /tmp/wrap/gcc.specs so that it calls llvm-ld* instead of real
>>   ld and does not pass any unknown flags to it.
>>
>> With this approach I was able to compile and run airstrike (a 2d
>> dogfighting game) in bitcode form very transparently with:
>>
>> $ make-bitcode fakeroot apt-get --build source airstrike
>> $ sudo dpkg -i airstrike*.deb
>> $ airstrike
> 
> Very clever though. :)
> 
>  - Daniel
> 
>> If you are interested I can try to rework my scripts to a shape where
>> they could be used by somebody else.
>>
>> (*) I am not actually calling llvm-ld directly. Instead I have an
>>    "llvm-ld-exe" wrapper that calls llvm-ld and then uses "anytoexe" to
>>    pack the resulting bitcode to a shell script that can execute itself with
>>    lli and use the correct -load options.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> 


From edwintorok at gmail.com  Fri Oct 16 01:27:05 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Fri, 16 Oct 2009 09:27:05 +0300
Subject: [LLVMdev] [Fwd: Re:  strace for whole-program bitcodes]
In-Reply-To: <600C0C33850FFE49B76BDD81AED4D2580132080E32@IMCMBX3.MITRE.ORG>
References: <4AD76184.4050000@kepps.net>
	<600C0C33850FFE49B76BDD81AED4D2580132080E32@IMCMBX3.MITRE.ORG>
Message-ID: <4AD81239.1090509@gmail.com>

On 2009-10-15 21:30, Keppler, Dave wrote:
>>>> someone suggested me to use gold-plugin, I know nothing about it yet, I
>>>>         
>> will
>>     
>>>> have a try later.  Does anyone have a good solution for this problem?
>>>>         
>>> Afaik gold does not help here. I tried it and managed to only generate
>>> native code.
>>>       
>> "Just" gold isn't quite good enough, because at the last final link
>> steps gold will still generate native code. However, it should be
>> possible to find a way to get gold to leave the merged bitcode around
>> somewhere, or perhaps do something like llvm-ld. Nicholas?
>>
>>     
>
> I've had some success by adding a call to lto_codegen_write_merged_modules(cg, somePath) at the end of the gold plugin's all_symbols_read_hook() function just before it calls lto_codegen_dispose(cg).  The somePath is set via a plugin option which I patched llvm-gcc to pass through as a derivation from its -o argument.
>
> It has worked on several mid-complexity applications I've tried so far (lighttpd, wu-ftpd, tcdump, and the sqlite library).
>
> I would be interested in seeing more of Timo's solution.  My goal is to eventually have a way to get bitcode + lli script outputs for off the shelf applications without modifying their make files.
>
>   

My way of getting whole program bitcodes is (you can use clang for CC)
for projects using autoconf and automake:
export CC=llvm-gcc
export CXX=llvm-g++
./configure --disable-shared
make CPPFLAGS="-O0 -g -emit-llvm" CCLD="llvm-ld -disable-opt" CFLAGS= -j4

I had to use CPPFLAGS instead of CFLAGS because llvm-ld doesn't
understand -O0 and -g, also it doesn't work to put CCLD on the configure
invocation line, it only works on the make invocation line.

Best regards,
--Edwin

From xuzhongxing at gmail.com  Fri Oct 16 01:42:51 2009
From: xuzhongxing at gmail.com (Zhongxing Xu)
Date: Fri, 16 Oct 2009 14:42:51 +0800
Subject: [LLVMdev] [cfe-dev] Command Line Bugzilla
In-Reply-To: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>
References: <6a8523d60910151809h75664a3eh876472a624266a23@mail.gmail.com>
Message-ID: <5400aeb80910152342x4c87f500r47f6ffbaafcdbf87@mail.gmail.com>

Hi Daniel,

Thanks. I'm using it. It's handy.

2009/10/16 Daniel Dunbar <daniel at zuster.org>:
> Hi all,
>
> Thought this might be of general interest, I hacked up the pybugz tool
> to work with llvm.org. It's here if you want it:
> ?http://t1.minormatter.com/~ddunbar/pybugz-llvm-0.7.3.tgz
>
> Unpack somewhere, and make a link to the 'bugz' script. Usage:
> --
> ddunbar at ozzy-2:~$ bugz get 1000
> ?* Using http://llvm.org/bugs/
> ?* Getting bug 1000 ..
> Title ? ? ? : Chris Is Buggy
> Assignee ? ?: tonic at nondot.org
> ...
>
> ddunbar at ozzy-2:~$ bugz search foo
> ?* Using http://llvm.org/bugs/
> ?* Searching for 'foo'
> ? 3053 unassignedclangbugs ?clang doesn't check foo(int a[static 10]) callers
> ? 3984 unassignedclangbugs ?[driver] clang foo.c -std=c++98 doesn't treat inpu
> ? 4120 unassignedclangbugs ?better error recovery for digraph confusion: <::fo
> ? 4519 kremenek ? ? ? ? ? ? [[[[Foo alloc] init] bar] release] marked as Bad r
> ? 4941 unassignedclangbugs ?clang-cc should support -fno-builtin-foo
> --
>
> Various parameters are probably hard coded to my usage, use at your
> own risk. I usually don't create bugs with it, just search and fetch.
>
> I find its much nicer for searching bugzilla, in particular.
>
> ?- Daniel
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


From Fons.Rademakers at cern.ch  Fri Oct 16 02:52:02 2009
From: Fons.Rademakers at cern.ch (Fons Rademakers)
Date: Fri, 16 Oct 2009 09:52:02 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD82622.8090301@cern.ch>

Hi Chris,

   it would be good if "the powers that be" could be made to understand 
that if only Apple employees are not allowed to put up their slides while 
Apple is employing the core of the LLVM foundation, that this sends the 
absolute wrong message on openness of the project. It is also totally 
incompatible with the fantastic work you guys are doing and your tremendous 
presence on the (non Apple) uiuc mailings lists.

At CERN we had already a number of people questioning the wisdom of basing 
our developments on LLVM as it is perceived as an Apple thing, that could 
turn on us at anytime, and this position does not help.

Cheers, Fons.


Chris Lattner wrote:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>> Hi, Chris
>>
>>> All of the videos are now up on the web page, and most of the slides
>>> are up (still need to get David's and Evan's slides).  Please let me
>>> know if you hit any problems.
>> First of all, thanks a lot about all stuff with videos & slides  
>> posting.
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.
> 
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers at cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640

From Axel.Naumann at cern.ch  Fri Oct 16 03:11:25 2009
From: Axel.Naumann at cern.ch (Axel Naumann)
Date: Fri, 16 Oct 2009 10:11:25 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD82AAD.9060408@cern.ch>

Hi Chris,

Chris Lattner wrote on 10/15/2009 05:45 PM:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.

can you maybe ask a public relations colleague to post at least the
slides? Even if it takes a while: not having them at all is very bad
publicity for Apple. It proves (esp to people like GCC, but also
colleagues here at CERN) that Apple is the wrong place to host an open
source project, and that Apple is doing its best at diverting efforts
into its proprietary domain.

Don't get me wrong: I really appreciate Apple's efforts in hosting the
workshop and paying 90% of the developers of LLVM!

Cheers, Axel.


From da.waterworth at googlemail.com  Fri Oct 16 04:40:14 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Fri, 16 Oct 2009 10:40:14 +0100
Subject: [LLVMdev] MallocInst/CallInst bitcast,
Message-ID: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>

Hello,

I'm writing a virtual machine that functions as a sandbox based on llvm. In
order to prevent programs from accessing memory that has not been allocated
to them, I want to replace calls to malloc and free with calls to a logged
functions that will record the memory that is being allocated to the
program. Is it possible to cast/convert a MallocInst or FreeInst to a
CallInst?

Thanks,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/793e9d36/attachment.html 

From da.waterworth at googlemail.com  Fri Oct 16 06:43:30 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Fri, 16 Oct 2009 12:43:30 +0100
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
Message-ID: <7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>

Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and
DisableSymbolSearching to cause malloc and free calls to be handled by my
logging functions. Sorry for the unnecessary list mail.

Is it possible to find out the size and beginning pointer of the current
stack frame, from a function operating outside of the virtual machine, but
called by a function within it?

Thanks,

Daniel

2009/10/16 Daniel Waterworth <da.waterworth at googlemail.com>

> Hello,
>
> I'm writing a virtual machine that functions as a sandbox based on llvm. In
> order to prevent programs from accessing memory that has not been allocated
> to them, I want to replace calls to malloc and free with calls to a logged
> functions that will record the memory that is being allocated to the
> program. Is it possible to cast/convert a MallocInst or FreeInst to a
> CallInst?
>
> Thanks,
>
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/c0d67813/attachment.html 

From nicolas at capens.net  Fri Oct 16 07:50:05 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Fri, 16 Oct 2009 14:50:05 +0200
Subject: [LLVMdev] getIntrinsicID() optimization
Message-ID: <003d01ca4e5f$2fd1f8f0$8f75ead0$@net>

Hi all,

 

While profiling I discovered that the Function::getIntrinsicID() method is
called a lot, and every time it uses string comparison to recompute the ID
number. As far as I know the name of an intrinsic function doesn't change,
so the ID could be determined just once at Function construction time.

 

I've attached a patch that does this and it appears to work for the code I
tested it with. Could anyone look at potential caveats and if there are none
commit it?

 

Thanks,

 

Nicolas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/480f2c24/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FastIntrinsicID.patch
Type: application/octet-stream
Size: 1569 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/480f2c24/attachment.obj 

From clattner at apple.com  Fri Oct 16 11:26:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Oct 2009 09:26:45 -0700
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
	<7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>
Message-ID: <851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>


On Oct 16, 2009, at 4:43 AM, Daniel Waterworth wrote:

> Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and  
> DisableSymbolSearching to cause malloc and free calls to be handled  
> by my logging functions. Sorry for the unnecessary list mail.

No problem, this is a better way to go.  The MallocInst and FreeInst  
instructions are about to be removed from LLVM IR.  Malloc and free  
will be represented normal 'call' instructions.

> Is it possible to find out the size and beginning pointer of the  
> current stack frame, from a function operating outside of the  
> virtual machine, but called by a function within it?

I don't think so.  Typically, applications that need this sort of  
thing get the address of the function and then do a fuzzy disassembly  
of the prolog.

-Chris

>
> Thanks,
>
> Daniel
>
> 2009/10/16 Daniel Waterworth <da.waterworth at googlemail.com>
> Hello,
>
> I'm writing a virtual machine that functions as a sandbox based on  
> llvm. In order to prevent programs from accessing memory that has  
> not been allocated to them, I want to replace calls to malloc and  
> free with calls to a logged functions that will record the memory  
> that is being allocated to the program. Is it possible to cast/ 
> convert a MallocInst or FreeInst to a CallInst?
>
> Thanks,
>
> Daniel
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/efa96b69/attachment.html 

From dag at cray.com  Fri Oct 16 12:36:35 2009
From: dag at cray.com (David Greene)
Date: Fri, 16 Oct 2009 12:36:35 -0500
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <4AD82622.8090301@cern.ch>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<4AD82622.8090301@cern.ch>
Message-ID: <200910161236.35627.dag@cray.com>

On Friday 16 October 2009 02:52, Fons Rademakers wrote:

> At CERN we had already a number of people questioning the wisdom of basing
> our developments on LLVM as it is perceived as an Apple thing, that could
> turn on us at anytime, and this position does not help.

Ditto.  I've heard this more than once from people here.

                              -Dave

From da.waterworth at googlemail.com  Fri Oct 16 13:21:28 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Fri, 16 Oct 2009 19:21:28 +0100
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
	<7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>
	<851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>
Message-ID: <7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>

Thanks very much. I only have one more question, (hopefully), which is, is
there a better way of finding the direction of stack growth other than:

static bool StackCmp(void *ptr) {
  volatile int a;
  return (void *)&a > ptr;
}

bool FindStackDirection() {
  volatile int a;
  return StackCmp((void *)&a);
}

Preferably one which isn't destroyed by optimization.

Thanks again,

Daniel

2009/10/16 Chris Lattner <clattner at apple.com>

>
> On Oct 16, 2009, at 4:43 AM, Daniel Waterworth wrote:
>
> Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and
> DisableSymbolSearching to cause malloc and free calls to be handled by my
> logging functions. Sorry for the unnecessary list mail.
>
>
> No problem, this is a better way to go.  The MallocInst and FreeInst
> instructions are about to be removed from LLVM IR.  Malloc and free will be
> represented normal 'call' instructions.
>
> Is it possible to find out the size and beginning pointer of the current
> stack frame, from a function operating outside of the virtual machine, but
> called by a function within it?
>
>
> I don't think so.  Typically, applications that need this sort of thing get
> the address of the function and then do a fuzzy disassembly of the prolog.
>
> -Chris
>
>
> Thanks,
>
> Daniel
>
> 2009/10/16 Daniel Waterworth <da.waterworth at googlemail.com>
>
>> Hello,
>>
>> I'm writing a virtual machine that functions as a sandbox based on llvm.
>> In order to prevent programs from accessing memory that has not been
>> allocated to them, I want to replace calls to malloc and free with calls to
>> a logged functions that will record the memory that is being allocated to
>> the program. Is it possible to cast/convert a MallocInst or FreeInst to a
>> CallInst?
>>
>> Thanks,
>>
>> Daniel
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/4b65f92e/attachment.html 

From espindola at google.com  Fri Oct 16 14:00:24 2009
From: espindola at google.com (Rafael Espindola)
Date: Fri, 16 Oct 2009 15:00:24 -0400
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <4AD82AAD.9060408@cern.ch>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<4AD82AAD.9060408@cern.ch>
Message-ID: <38a0d8450910161200i40d737d7r5bfd86dd6c8f7044@mail.gmail.com>

> can you maybe ask a public relations colleague to post at least the
> slides? Even if it takes a while: not having them at all is very bad
> publicity for Apple. It proves (esp to people like GCC, but also
> colleagues here at CERN) that Apple is the wrong place to host an open
> source project, and that Apple is doing its best at diverting efforts
> into its proprietary domain.

I was told that before when setting up a previous project:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-April/005663.html

Once one is actually involved in the llvm development, it is very
nice. Just avoiding bad PR would probably get more people in.

>
> Cheers, Axel.

Cheers,
-- 
Rafael ?vila de Esp?ndola


From listiges at arcor.de  Fri Oct 16 14:59:16 2009
From: listiges at arcor.de (Nico)
Date: Fri, 16 Oct 2009 21:59:16 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <2C2ECF4B05BCF3489866AB805260FEC504CE39F3A0@rrsmsx509.amr.corp.intel.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<2C2ECF4B05BCF3489866AB805260FEC504CE39F3A0@rrsmsx509.amr.corp.intel.com>
Message-ID: <8490BD1E-0BC9-471D-8DF0-44A39A03267E@arcor.de>

Hi,

On Oct 15, 2009, at 6:34 PM, Du Toit, Stefanus wrote:

> I expect a lot of people would be very interested in Nate's OpenCL  
> talk as well, given the current interest in OpenCL and that it's a  
> nice real-world example of LLVM usage.

I know at least one who is interested!

Slides would be very nice.

Ciao,
Nico

From juanc.martinez.santos at gmail.com  Fri Oct 16 15:22:34 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Fri, 16 Oct 2009 16:22:34 -0400
Subject: [LLVMdev] named address spaces
Message-ID: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>

Hello,

If my understand is correct, LLVM supports the address_space qualifier;
however, how I can add custom address spaces. Where I can declare them? For
clang (x86), I saw that address spaces #256 and #257 works well (I see the
generated code with the 'gs' and 'fs'), but when I select different ones, I
don't see any different.

Thanks in advance,

-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/2b88738e/attachment.html 

From clattner at apple.com  Fri Oct 16 15:34:10 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Oct 2009 13:34:10 -0700
Subject: [LLVMdev] named address spaces
In-Reply-To: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
References: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
Message-ID: <0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>


On Oct 16, 2009, at 1:22 PM, Juan Carlos Martinez Santos wrote:

> Hello,
>
> If my understand is correct, LLVM supports the address_space  
> qualifier; however, how I can add custom address spaces. Where I can  
> declare them? For clang (x86), I saw that address spaces #256 and  
> #257 works well (I see the generated code with the 'gs' and 'fs'),  
> but when I select different ones, I don't see any different.
>

Address spaces are target specific.  The 256/257 address spaces on x86  
are implemented in the X86 backend, for example.

-Chris


From clattner at apple.com  Fri Oct 16 15:35:23 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Oct 2009 13:35:23 -0700
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
	<7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>
	<851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>
	<7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>
Message-ID: <879ADB4C-3324-4AB5-9F86-7285271253AB@apple.com>


On Oct 16, 2009, at 11:21 AM, Daniel Waterworth wrote:

> Thanks very much. I only have one more question, (hopefully), which  
> is, is there a better way of finding the direction of stack growth  
> other than:

That's a somewhat reasonable, but fragile way to go.  Make sure to  
mark StackCmp with attribute(noinline).  Don't be too surprised if it  
doesn't work on some compiler.  I don't know a better way to do it  
though.

-Chris

>
> static bool StackCmp(void *ptr) {
>   volatile int a;
>   return (void *)&a > ptr;
> }
>
> bool FindStackDirection() {
>   volatile int a;
>   return StackCmp((void *)&a);
> }
>
> Preferably one which isn't destroyed by optimization.
>
> Thanks again,
>
> Daniel
>
> 2009/10/16 Chris Lattner <clattner at apple.com>
>
> On Oct 16, 2009, at 4:43 AM, Daniel Waterworth wrote:
>
>> Never mind, I used ExecutionEngine's InstallLazyFunctionCreator and  
>> DisableSymbolSearching to cause malloc and free calls to be handled  
>> by my logging functions. Sorry for the unnecessary list mail.
>
> No problem, this is a better way to go.  The MallocInst and FreeInst  
> instructions are about to be removed from LLVM IR.  Malloc and free  
> will be represented normal 'call' instructions.
>
>> Is it possible to find out the size and beginning pointer of the  
>> current stack frame, from a function operating outside of the  
>> virtual machine, but called by a function within it?
>
> I don't think so.  Typically, applications that need this sort of  
> thing get the address of the function and then do a fuzzy  
> disassembly of the prolog.
>
> -Chris
>
>>
>> Thanks,
>>
>> Daniel
>>
>> 2009/10/16 Daniel Waterworth <da.waterworth at googlemail.com>
>> Hello,
>>
>> I'm writing a virtual machine that functions as a sandbox based on  
>> llvm. In order to prevent programs from accessing memory that has  
>> not been allocated to them, I want to replace calls to malloc and  
>> free with calls to a logged functions that will record the memory  
>> that is being allocated to the program. Is it possible to cast/ 
>> convert a MallocInst or FreeInst to a CallInst?
>>
>> Thanks,
>>
>> Daniel
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/9bdd1ac6/attachment.html 

From c.r1 at gmx.de  Fri Oct 16 15:36:14 2009
From: c.r1 at gmx.de (Cornelius)
Date: Fri, 16 Oct 2009 22:36:14 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <200910161236.35627.dag@cray.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>	<4AD82622.8090301@cern.ch>
	<200910161236.35627.dag@cray.com>
Message-ID: <4AD8D93E.1020206@gmx.de>

On 10/16/2009 07:36 PM, David Greene wrote:
> On Friday 16 October 2009 02:52, Fons Rademakers wrote:
>
>> At CERN we had already a number of people questioning the wisdom of basing
>> our developments on LLVM as it is perceived as an Apple thing, that could
>> turn on us at anytime, and this position does not help.
>
> Ditto.  I've heard this more than once from people here.
>
>                                -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
In my opinion, it's not just about that aspect. Not having openess in an 
OS project is bad, but in this case, I wasn't able to make it to the 
meeting, and I've a strong personal interest in clang, and I'd really 
like to watch the State of clang talk.
Also the OpenCL talk (probably, as I don't know...) contains lots of 
interesting news about an upcoming technology which will be probably 
very important for every professional who wants to use parallelism and 
GPU computing power efficiently (efficient as in less dev time for more 
performance).
And that's just beside the bad PR which will be (probably) soon picked 
up by news sites.
Let's hope that the responsible person for this changes his/her mind 
soon,  so everyone can calm down.
Cornelius

From dag at cray.com  Fri Oct 16 15:45:57 2009
From: dag at cray.com (David Greene)
Date: Fri, 16 Oct 2009 15:45:57 -0500
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <4AD8D93E.1020206@gmx.de>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<200910161236.35627.dag@cray.com> <4AD8D93E.1020206@gmx.de>
Message-ID: <200910161545.57727.dag@cray.com>

On Friday 16 October 2009 15:36, Cornelius wrote:

> In my opinion, it's not just about that aspect. Not having openess in an
> OS project is bad, but in this case, I wasn't able to make it to the
> meeting, and I've a strong personal interest in clang, and I'd really
> like to watch the State of clang talk.
> Also the OpenCL talk (probably, as I don't know...) contains lots of
> interesting news about an upcoming technology which will be probably
> very important for every professional who wants to use parallelism and
> GPU computing power efficiently (efficient as in less dev time for more
> performance).
> And that's just beside the bad PR which will be (probably) soon picked
> up by news sites.

But it's more than just PR.  When I agreed to be a speaker, I signed off on
having my talk made publicly available.  There does seem to be a
double-standard here and that's concerning.

I understand that none of the Apple speakers are happy about this.  Corporate
paranoia is the problem here.

                               -Dave

From skaflotten at gmail.com  Fri Oct 16 15:58:21 2009
From: skaflotten at gmail.com (srs)
Date: Fri, 16 Oct 2009 22:58:21 +0200
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>	<7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>	<851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>
	<7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>
Message-ID: <4AD8DE6D.3000002@gmail.com>

Daniel Waterworth skrev:
> Thanks very much. I only have one more question, (hopefully), which 
> is, is there a better way of finding the direction of stack growth 
> other than:
>
> static bool StackCmp(void *ptr) {
>   volatile int a;
>   return (void *)&a > ptr;
> }
>
> bool FindStackDirection() {
>   volatile int a;
>   return StackCmp((void *)&a);
> }
>
> Preferably one which isn't destroyed by optimization.

I suggest you turn the scalars into arrays and make the ptr argument 
volatile as well.

Other ways: If you are careful with tail recursion eliminiation, you can 
compare local var addresses from different recursive calls. I believe 
there are va_arg based approaches as well.

That said, there is no truly portable way.

/Stein Roger

From juanc.martinez.santos at gmail.com  Fri Oct 16 16:30:30 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Fri, 16 Oct 2009 17:30:30 -0400
Subject: [LLVMdev] named address spaces
In-Reply-To: <0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
References: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
	<0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
Message-ID: <d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>

Hello,

If I want implement other address spaces (for x86), can I modify my back-end
(clang) to support other address spaces (at least two data segments, two
heaps, and two stacks?

How will be the mechanism? For example, for256/257, I see two reference
points (FS and GP). Would I need to specify a different reference to
each memory region? Where is the best site to add the modifications?

Thanks in advance,

Juan Carlos

On Fri, Oct 16, 2009 at 4:34 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Oct 16, 2009, at 1:22 PM, Juan Carlos Martinez Santos wrote:
>
> Hello,
>>
>> If my understand is correct, LLVM supports the address_space qualifier;
>> however, how I can add custom address spaces. Where I can declare them? For
>> clang (x86), I saw that address spaces #256 and #257 works well (I see the
>> generated code with the 'gs' and 'fs'), but when I select different ones, I
>> don't see any different.
>>
>>
> Address spaces are target specific.  The 256/257 address spaces on x86 are
> implemented in the X86 backend, for example.
>
> -Chris
>
>


-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091016/6e0fc993/attachment.html 

From clattner at apple.com  Fri Oct 16 23:05:16 2009
From: clattner at apple.com (Chris Lattner)
Date: Fri, 16 Oct 2009 21:05:16 -0700
Subject: [LLVMdev] [cfe-dev]  named address spaces
In-Reply-To: <d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>
References: <d17b77a40910161322g2b0053adj1ca4ce39fd0dcc37@mail.gmail.com>
	<0727CC2A-B8A7-4975-83B3-B368E27F568B@apple.com>
	<d17b77a40910161430k60178f1k4b8dab4a5b74c463@mail.gmail.com>
Message-ID: <C8641A62-4332-45B9-B07D-6C568FEF055E@apple.com>


On Oct 16, 2009, at 2:30 PM, Juan Carlos Martinez Santos wrote:

> Hello,
>
> If I want implement other address spaces (for x86), can I modify my  
> back-end (clang) to support other address spaces (at least two data  
> segments, two heaps, and two stacks?
>
> How will be the mechanism? For example, for256/257, I see two  
> reference points (FS and GP). Would I need to specify a different  
> reference to each memory region? Where is the best site to add the  
> modifications?

I don't know what changes you'll need off hand.  I think you just  
refer to them (assigning a magic number) and handle them as the come  
through the IR.

-Chris


From hans at hanshq.net  Sat Oct 17 01:24:28 2009
From: hans at hanshq.net (Hans Wennborg)
Date: Sat, 17 Oct 2009 08:24:28 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <4AD9631C.5080400@hanshq.net>

I was really looking forward to watching the presentation about Scalar 
Evolution, as it is something I use in my ongoing thesis work.

I cannot possibly see how Apple would benefit from this policy.

/ Hans

Chris Lattner wrote:
> On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote:
>> Hi, Chris
>>
>>> All of the videos are now up on the web page, and most of the slides
>>> are up (still need to get David's and Evan's slides).  Please let me
>>> know if you hit any problems.
>> First of all, thanks a lot about all stuff with videos & slides  
>> posting.
>>
>> I'm a bit curious: is there any reason why are other slides / videos
>> not available (it seems that the ones missing are from Apple folks)?
> 
> Unfortunately, we found out at the last minute that Apple has a rule  
> which prevents its engineers from giving video taped talks or  
> distributing slides.  We will hold onto the video and slide assets in  
> case this rule changes in the future.
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From da.waterworth at googlemail.com  Sat Oct 17 02:34:04 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Sat, 17 Oct 2009 08:34:04 +0100
Subject: [LLVMdev] MallocInst/CallInst bitcast,
In-Reply-To: <4AD8DE6D.3000002@gmail.com>
References: <7a5a555b0910160240y5a68701ah1b683927645b7b38@mail.gmail.com>
	<7a5a555b0910160443mda3e9c1hf5170b79fd40efec@mail.gmail.com>
	<851AF606-13BA-4B0D-A7EE-CF3B901BD149@apple.com>
	<7a5a555b0910161121q3bd4011dted34c6f723c688ac@mail.gmail.com>
	<4AD8DE6D.3000002@gmail.com>
Message-ID: <7a5a555b0910170034i20d0a9f8t765ff7d39b303363@mail.gmail.com>

2009/10/16 srs <skaflotten at gmail.com>

> Daniel Waterworth skrev:
>
>> Thanks very much. I only have one more question, (hopefully), which is, is
>> there a better way of finding the direction of stack growth other than:
>>
>> static bool StackCmp(void *ptr) {
>>  volatile int a;
>>  return (void *)&a > ptr;
>> }
>>
>> bool FindStackDirection() {
>>  volatile int a;
>>  return StackCmp((void *)&a);
>> }
>>
>> Preferably one which isn't destroyed by optimization.
>>
>
> I suggest you turn the scalars into arrays and make the ptr argument
> volatile as well.
>
> Other ways: If you are careful with tail recursion eliminiation, you can
> compare local var addresses from different recursive calls. I believe there
> are va_arg based approaches as well.
>
> That said, there is no truly portable way.
>
> /Stein Roger
>

I've changed the ptr argument to volatile and the StackCmp function to
noinline. It's now providing the correct answer in gcc and llvm-gcc with
optimization on -O3. This will suite my puposes, at least for the time
being.

Thanks alot,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/52ef2df0/attachment.html 

From resistor at mac.com  Sat Oct 17 03:32:10 2009
From: resistor at mac.com (Owen Anderson)
Date: Sat, 17 Oct 2009 01:32:10 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <C3477096-20FF-456B-BF4A-C6932770116D@mac.com>

Chris,

On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote:
> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.


While I'm glad to know we all share similar sentiments on this, lots  
of "me too" emails on this list don't seem likely to change anything.   
Is there anyone we can email to express our displeasure at this  
decision, so that we might have some vague chance of having an impact?

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2620 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/1d1343a9/attachment.bin 

From csdavec at swansea.ac.uk  Sat Oct 17 05:34:00 2009
From: csdavec at swansea.ac.uk (David Chisnall)
Date: Sat, 17 Oct 2009 11:34:00 +0100
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <9A38B63C-16CA-4937-8EE6-F6865F5EEEF1@swan.ac.uk>

On 15 Oct 2009, at 16:45, Chris Lattner wrote:

> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.

Is this a new policy?  I note that there are still videos and slides  
up from Apple developers - including yourself - from previous dev  
meetings.  If an exception was made in the past, is there a reason why  
it isn't being made again?

David

-- Send from my Jacquard Loom


From nicolas at capens.net  Sat Oct 17 05:48:05 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Sat, 17 Oct 2009 12:48:05 +0200
Subject: [LLVMdev] getIntrinsicID() optimization, mark 2
Message-ID: <003601ca4f17$4ea7c3a0$ebf74ae0$@net>

Any takers? This patch improves on the previous one by making
getIntrinsicID() inline.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/9406e0ad/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FastIntrinsicID-2.patch
Type: application/octet-stream
Size: 2587 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/9406e0ad/attachment.obj 

From eocallaghan at auroraux.org  Sat Oct 17 08:12:58 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Sat, 17 Oct 2009 14:12:58 +0100
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <9A38B63C-16CA-4937-8EE6-F6865F5EEEF1@swan.ac.uk>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<9A38B63C-16CA-4937-8EE6-F6865F5EEEF1@swan.ac.uk>
Message-ID: <521640720910170612r3d41b7a0mac0eb10478a88365@mail.gmail.com>

G'Day,

As this has turned into somewhat of a partition to 'open source' the
videos, here is my +1.

Cheers,
Edward O'Callaghan.

2009/10/17 David Chisnall <csdavec at swansea.ac.uk>:
> On 15 Oct 2009, at 16:45, Chris Lattner wrote:
>
>> Unfortunately, we found out at the last minute that Apple has a rule
>> which prevents its engineers from giving video taped talks or
>> distributing slides. ?We will hold onto the video and slide assets in
>> case this rule changes in the future.
>
> Is this a new policy? ?I note that there are still videos and slides
> up from Apple developers - including yourself - from previous dev
> meetings. ?If an exception was made in the past, is there a reason why
> it isn't being made again?
>
> David
>
> -- Send from my Jacquard Loom
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From jyasskin at google.com  Sat Oct 17 12:03:15 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Sat, 17 Oct 2009 10:03:15 -0700
Subject: [LLVMdev] getIntrinsicID() optimization, mark 2
In-Reply-To: <003601ca4f17$4ea7c3a0$ebf74ae0$@net>
References: <003601ca4f17$4ea7c3a0$ebf74ae0$@net>
Message-ID: <bb55930e0910171003j550a872fo32679537c26d148e@mail.gmail.com>

It is possible to change the name of a Function with Value::setName,
so this patch _could_ cause incorrect answers. You should add a test
that calls setName("intrinsic.name") to make sure this keeps working,
regardless of where this patch goes.  You might be able to catch such
events in the ValueSymbolTable and update the intrinsic ID, but I
can't find an obvious place to put that code.

I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is
a switch statement on the first letter of the intrinsic name plus a
long series of
    if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return
Intrinsic::alpha_umulh;
    if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return
Intrinsic::annotation;
    if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return
Intrinsic::arm_neon_vabals;
...

There has to be a more efficient way to do this. If nothing else, the
first 6 characters of that memcmp are always equal, and for groups of
intrinsics like llvm.arm.neon.v*, a trie-like search would be better.
llvm/ADT/Trie.h doesn't quite do what this needs (no prefix
searching), and it looks like it should be changed to use StringRefs
instead of std::strings during the search, but fixing and using it
here might be the right thing to do.

On Sat, Oct 17, 2009 at 3:48 AM, Nicolas Capens <nicolas at capens.net> wrote:
> Any takers? This patch improves on the previous one by making
> getIntrinsicID() inline.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From mmwu at Princeton.EDU  Sat Oct 17 12:16:19 2009
From: mmwu at Princeton.EDU (Michael Wu)
Date: Sat, 17 Oct 2009 13:16:19 -0400
Subject: [LLVMdev] Build errors for vmkit
Message-ID: <4AD9FBE3.7000105@princeton.edu>

Hi,

    I can't seem to get VMKit to compile correctly. I'm on a 64 bit 
Jaunty system. I compiled llvm and llvm-gcc from the subversion source 
no problem, but when I try to compile VMKit I get some issue with 
GCAllocator:

/home/mmwu/Download/llvm$ ./configure
/home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1
/home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install

...

/home/mmwu/Download/$ sudo apt-get install classpath

...

/home/mmwu/Download/vmkit$ ./configure 
--with-llvmsrc=/home/mmwu/Download/llvm 
--with-llvmobj=/home/mmwu/Download/llvm 
--with-gnu-classpath-glibj=/usr/share/classpath/glibj.zip 
--with-gnu-classpath-libs=/usr/lib/classpath
/home/mmwu/Download/vmkit$ make ENABLE_OPTIMIZED=1

make[2]: Entering directory `/home/mmwu/Download/vmkit/tools/vmkit'
llvm[2]: Linking Release executable vmkit (without symbols)
/home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In 
function `mvm::Collector::destroy()':
gcinit.cpp:(.text+0x34): undefined reference to 
`GCAllocator::~GCAllocator()'
gcinit.cpp:(.text+0x3c): undefined reference to `GCAllocator::operator 
delete(void*)'
/home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In 
function `mvm::Collector::initialise()':
gcinit.cpp:(.text+0x216): undefined reference to `GCAllocator::operator 
new(unsigned long)'
gcinit.cpp:(.text+0x221): undefined reference to 
`GCAllocator::GCAllocator()'
gcinit.cpp:(.text+0x2d5): undefined reference to `GCAllocator::operator 
delete(void*)'
collect2: ld returned 1 exit status
make[2]: *** [/home/mmwu/Download/vmkit/Release/bin/vmkit] Error 1
make[2]: Leaving directory `/home/mmwu/Download/vmkit/tools/vmkit'
make[1]: *** [vmkit/.makeall] Error 2
make[1]: Leaving directory `/home/mmwu/Download/vmkit/tools'
make: *** [all] Error 1

I would really appreciate any help I could get.

Thanks,
Michael

From clattner at apple.com  Sat Oct 17 12:28:36 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Oct 2009 10:28:36 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
Message-ID: <56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>

On Oct 17, 2009, at 1:32 AM, Owen Anderson wrote:
> Chris,
>
> On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote:
>> Unfortunately, we found out at the last minute that Apple has a rule
>> which prevents its engineers from giving video taped talks or
>> distributing slides.  We will hold onto the video and slide assets in
>> case this rule changes in the future.
>
>
> While I'm glad to know we all share similar sentiments on this, lots  
> of "me too" emails on this list don't seem likely to change  
> anything.  Is there anyone we can email to express our displeasure  
> at this decision, so that we might have some vague chance of having  
> an impact?

The people enforcing this policy are applying a blanket policy to a  
situation which (IMO) makes no sense.  I forward every "disgruntled"  
email on to the people in question.  Since they are the defenders of  
"Apple's public image", it seems fairly possible that it may  
eventually sway them.  The more public the griping, the better.

So yes, 'me too' emails are potentially useful.

-Chris


From lattner at apple.com  Sat Oct 17 13:51:05 2009
From: lattner at apple.com (Tanya Lattner)
Date: Sat, 17 Oct 2009 11:51:05 -0700
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
Message-ID: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>

LLVMers,

2.6 pre-release2 is ready to be tested by the community.
http://llvm.org/prereleases/2.6/

If you have time, I'd appreciate anyone who can help test the release.

To test llvm-gcc:

1) Compile llvm from source and untar the llvm-test in the projects  
directory (name it llvm-test or test-suite). Choose to use a pre- 
compiled llvm-gcc or re-compile it yourself.
2) Run make check, report any failures (FAIL or unexpected pass). Note  
that you need to reconfigure llvm with llvm-gcc in your path or with -- 
with-llvmgccdir
3) Run "make TEST=nightly report" and send me the report.nightly.txt


To test clang:
1) Compile llvm and clang from source.
2) Run make check for llvm.
3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or  
unexpected passes)

When reporting your results, please provide details on what platform  
you compiled on, and how
you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.

Please COMPLETE ALL TESTING BY 5pm PDT on October 21st!

Thanks,
Tanya Lattner

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/6943a2e0/attachment.html 

From mierle at gmail.com  Sat Oct 17 14:01:03 2009
From: mierle at gmail.com (Keir Mierle)
Date: Sat, 17 Oct 2009 12:01:03 -0700
Subject: [LLVMdev] Developer meeting videos up
In-Reply-To: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
Message-ID: <ef5675f30910171201j77a0ccaerd27d44e47dda4630@mail.gmail.com>

I'm pretty disappointed that the Clang and Scalar Evolution talks are not
available. I couldn't make the dev meeting this year; however, I figured the
videos and slides would still be available. Apple is sending the wrong
message; don't they want to promote the idea that LLVM is an open project
and not just Apple owned? It's silly to reinforce the fear around LLVM that
Apple will close further development.
The blanket policy enforcement is ridiculous in this case.

Keir

On Thu, Oct 15, 2009 at 12:05 AM, Chris Lattner <clattner at apple.com> wrote:

> Hi All,
>
> All of the videos are now up on the web page, and most of the slides
> are up (still need to get David's and Evan's slides).  Please let me
> know if you hit any problems.
>
> You can access the content here:
> http://llvm.org/devmtg/2009-10/
>
> FYI, one room recorded a screencast and the other was recorded with a
> standalone camera.  This means that you can't see the speakers in one
> room, which is unfortunate but much better than no video :).
>
> I want to send a huge thanks to Jason Molenda.  Not only did he
> contribute his equipment to record the event, he also collected a
> tremendous amount of the content, edited the videos, transcoded them
> and did a lot of other great work.  Getting nice videos up takes a lot
> more work than it seems, and the video quality is very high this
> year.  Thank you Jason!
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/e92f2ee1/attachment.html 

From joe at alacatialabs.com  Sat Oct 17 14:51:08 2009
From: joe at alacatialabs.com (Joseph Ranieri)
Date: Sat, 17 Oct 2009 15:51:08 -0400
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
	<56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
Message-ID: <5D33B94A-721F-4F77-BABE-8D7ED2155B2E@alacatialabs.com>


On Oct 17, 2009, at 1:28 PM, Chris Lattner wrote:

> On Oct 17, 2009, at 1:32 AM, Owen Anderson wrote:
>> Chris,
>>
>> On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote:
>>> Unfortunately, we found out at the last minute that Apple has a rule
>>> which prevents its engineers from giving video taped talks or
>>> distributing slides.  We will hold onto the video and slide assets  
>>> in
>>> case this rule changes in the future.
>>
>>
>> While I'm glad to know we all share similar sentiments on this, lots
>> of "me too" emails on this list don't seem likely to change
>> anything.  Is there anyone we can email to express our displeasure
>> at this decision, so that we might have some vague chance of having
>> an impact?
>
> The people enforcing this policy are applying a blanket policy to a
> situation which (IMO) makes no sense.  I forward every "disgruntled"
> email on to the people in question.  Since they are the defenders of
> "Apple's public image", it seems fairly possible that it may
> eventually sway them.  The more public the griping, the better.
>
> So yes, 'me too' emails are potentially useful.
>
> -Chris

A definite "me too" here. I went to the exception handling BoF instead  
of the OpenCL talk, expecting it to be online after.

-- Joe Ranieri

From edwintorok at gmail.com  Sat Oct 17 15:18:31 2009
From: edwintorok at gmail.com (=?ISO-8859-1?Q?T=F6r=F6k_Edwin?=)
Date: Sat, 17 Oct 2009 23:18:31 +0300
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
	<56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
Message-ID: <4ADA2697.6020904@gmail.com>

On 2009-10-17 20:28, Chris Lattner wrote:
> On Oct 17, 2009, at 1:32 AM, Owen Anderson wrote:
>   
>> Chris,
>>
>> On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote:
>>     
>>> Unfortunately, we found out at the last minute that Apple has a rule
>>> which prevents its engineers from giving video taped talks or
>>> distributing slides.  We will hold onto the video and slide assets in
>>> case this rule changes in the future.
>>>       
>> While I'm glad to know we all share similar sentiments on this, lots  
>> of "me too" emails on this list don't seem likely to change  
>> anything.  Is there anyone we can email to express our displeasure  
>> at this decision, so that we might have some vague chance of having  
>> an impact?
>>     
>
> The people enforcing this policy are applying a blanket policy to a  
> situation which (IMO) makes no sense.  I forward every "disgruntled"  
> email on to the people in question.  Since they are the defenders of  
> "Apple's public image", it seems fairly possible that it may  
> eventually sway them.  The more public the griping, the better.
>
> So yes, 'me too' emails are potentially useful.
>   

I would be especially interested in the Scalar Evolution, and Register
Allocation talks (and I wouldn't mind seeing the other Apple talks
either,  for example OpenCL is not something of immediate interest to
me, but perhaps something in the talk could prove interesting/useful).
I think having the talks available is a great way to show Apple's
accomplishments and involvement in LLVM.
I don't know what the reason is behind Apple's policy, there's certainly
nothing to be ashamed about regarding these talks,
and they don't discuss the secret internal workings of an Apple product:
the code for everything that is discussed is publicly available AFAIK.

Either way the people who attended the meeting were able to see and hear
everything, not making the talks available to others only results in
disappointment.

Maybe Apple's marketing dept. could approve each video/slide on a case
by case basis?

Best regards,
--Edwin

From clattner at apple.com  Sat Oct 17 15:53:56 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Oct 2009 13:53:56 -0700
Subject: [LLVMdev] getIntrinsicID() optimization
In-Reply-To: <003d01ca4e5f$2fd1f8f0$8f75ead0$@net>
References: <003d01ca4e5f$2fd1f8f0$8f75ead0$@net>
Message-ID: <7980C3AD-1396-454A-A82D-70E012DD9CDA@apple.com>


On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote:

> Hi all,
>
> While profiling I discovered that the Function::getIntrinsicID()  
> method is called a lot, and every time it uses string comparison to  
> recompute the ID number. As far as I know the name of an intrinsic  
> function doesn?t change, so the ID could be determined just once at  
> Function construction time.
>
> I?ve attached a patch that does this and it appears to work for the  
> code I tested it with. Could anyone look at potential caveats and if  
> there are none commit it?

Hi Nicolas,

Sorry for the delay.  I don't think that this is the right way to go.   
Making Function larger is an extremely expensive thing to do.  There  
are use cases in LLVM where apps load large modules lazily and stream  
in functions on demand.  The way this works currently is that the  
function objects are created eagerly, but their bodies are lazy.   
Increasing hte size of function can substantially penalize these cases.

Also, as Jeffrey points out, it is not safe with setName().

However, this would be a great thing to have.  Instead of adding a new  
field, is there space in the "SubClassData" field in Value?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/8f406521/attachment.html 

From arelius at gmail.com  Sat Oct 17 16:21:39 2009
From: arelius at gmail.com (Nicholas "Indy" Ray)
Date: Sat, 17 Oct 2009 14:21:39 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <4ADA2697.6020904@gmail.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
	<56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
	<4ADA2697.6020904@gmail.com>
Message-ID: <b45520600910171421h48051914v768ca0d110eb76e5@mail.gmail.com>

2009/10/17 T?r?k Edwin <edwintorok at gmail.com>:
> Either way the people who attended the meeting were able to see and hear
> everything, not making the talks available to others only results in
> disappointment.

The slides and video would be very nice even for those who did make it
to the meeting. As there were multiple sessions going on at a time
it's a given that we missed useful sessions, And beyond that I
personally didn't take many notes with the assumption that the slides
were going to be made available at the very least.

Nicholas "Indy" Ray


From rnk at mit.edu  Sat Oct 17 16:25:19 2009
From: rnk at mit.edu (Reid Kleckner)
Date: Sat, 17 Oct 2009 17:25:19 -0400
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com> 
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com> 
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com> 
	<56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
Message-ID: <9a9942200910171425r21170132o65c6257562251cba@mail.gmail.com>

> The people enforcing this policy are applying a blanket policy to a
> situation which (IMO) makes no sense. ?I forward every "disgruntled"
> email on to the people in question. ?Since they are the defenders of
> "Apple's public image", it seems fairly possible that it may
> eventually sway them. ?The more public the griping, the better.
>
> So yes, 'me too' emails are potentially useful.

Well, if Chris says so, then "me too!"

I'm a student at MIT and I would've loved to go see those talks, but I
was too busy to get back to the left coast.

When I talk to my friends about what I worked on over the summer, I
talk about LLVM, and now I have to mention this little addendum that
working with LLVM can be troublesome because of Apple's secrecy.  This
is a case in point.

ditto-ly,
Reid


From samuraileumas at yahoo.com  Sat Oct 17 16:28:06 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Sat, 17 Oct 2009 14:28:06 -0700 (PDT)
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<C3477096-20FF-456B-BF4A-C6932770116D@mac.com>
	<56AC7129-A4FE-4A71-A539-FC3EC0E7FF93@apple.com>
Message-ID: <855649.63446.qm@web62003.mail.re1.yahoo.com>

Hello LLVM Developers,

Here's a definite "me too" letter also.  My programming partner and I were planning on coming together in the same car for a 3 day drive there and another 3 day drive back... except that his wife gave birth about 2 or 3 weeks before the conference and he had to stay with her.  SInce I couldn't afford the gas for the trip myself that meant I couldn't come either.

I know that several flavors of BSD have made Clang their default compiler and at least one Linux distro in the works is planning on doing likewise.  Clang is one of the hottest cross-platform projects that open-source has to offer in the sense that it offers a plausible alternative to the GCC toolchain.  The possibility of a cross-compiling to a generic bitcode makes it even more valuable since it greatly simplifies the GCC problem of having to have a separate version of GCC or even LLVM-GCC for each platform being compiled for.

Maybe it would be more practical in future conferences for the Apple engineers to pass crib notes to the non-Apple people involved with the projects and just have non-Apple speakers from now on.  This should get around the rule.  I just hope we don't have to sign non-disclosure agreements upon arrival like some developers' conferences I've been to.

Perhaps next year I can come,

--Sam Crow


----- Original Message ----
> From: Chris Lattner <clattner at apple.com>
> To: Owen Anderson <resistor at mac.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Sat, October 17, 2009 12:28:36 PM
> Subject: Re: [LLVMdev] [cfe-dev] Developer meeting videos up
> 
> On Oct 17, 2009, at 1:32 AM, Owen Anderson wrote:
> > Chris,
> >
> > On Oct 15, 2009, at 8:45 AM, Chris Lattner wrote:
> >> Unfortunately, we found out at the last minute that Apple has a rule
> >> which prevents its engineers from giving video taped talks or
> >> distributing slides.  We will hold onto the video and slide assets in
> >> case this rule changes in the future.
> >
> >
> > While I'm glad to know we all share similar sentiments on this, lots  
> > of "me too" emails on this list don't seem likely to change  
> > anything.  Is there anyone we can email to express our displeasure  
> > at this decision, so that we might have some vague chance of having  
> > an impact?
> 
> The people enforcing this policy are applying a blanket policy to a  
> situation which (IMO) makes no sense.  I forward every "disgruntled"  
> email on to the people in question.  Since they are the defenders of  
> "Apple's public image", it seems fairly possible that it may  
> eventually sway them.  The more public the griping, the better.
> 
> So yes, 'me too' emails are potentially useful.
> 
> -Chris


      

From nicolas at capens.net  Sat Oct 17 18:08:24 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Sun, 18 Oct 2009 01:08:24 +0200
Subject: [LLVMdev] getIntrinsicID() optimization, mark 2
In-Reply-To: <bb55930e0910171003j550a872fo32679537c26d148e@mail.gmail.com>
References: <003601ca4f17$4ea7c3a0$ebf74ae0$@net>
	<bb55930e0910171003j550a872fo32679537c26d148e@mail.gmail.com>
Message-ID: <7F789AE2A937422F9DFBA0A6F45F1FE2@M65>

Hi Jeffrey,

Please correct me if I'm wrong, but I believe a test that checks for the old
behavior would be pointless. I realize that my patch would return an
unmatching intrinsicID when the function's name changes, but the real
question we should ask is do we really want to be able to change the
intrinsicID by changing the function's name?

Also, the original Function constructor contains this code:

// Ensure intrinsics have the right parameter attributes.
if (unsigned IID = getIntrinsicID())
    setAttributes(Intrinsic::getAttributes(Intrinsic::ID(IID)));

Note that if you hypothetically changed an intrinsic's name it's parameter
attributes could potentially become invalid...

It seems to me that intrinsic names were never intended to be changed in the
first place. That sounds perfectly reasonable to me, although it should
probably be documented somewhere. So unless there are tangible reasons why
intrinsics should actually be allowed to change name I believe my patch is
valid.

Cheers,

Nicolas


-----Original Message-----
From: Jeffrey Yasskin [mailto:jyasskin at google.com] 
Sent: Saturday, 17 October, 2009 19:03
To: Nicolas Capens
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] getIntrinsicID() optimization, mark 2

It is possible to change the name of a Function with Value::setName,
so this patch _could_ cause incorrect answers. You should add a test
that calls setName("intrinsic.name") to make sure this keeps working,
regardless of where this patch goes.  You might be able to catch such
events in the ValueSymbolTable and update the intrinsic ID, but I
can't find an obvious place to put that code.

I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is
a switch statement on the first letter of the intrinsic name plus a
long series of
    if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return
Intrinsic::alpha_umulh;
    if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return
Intrinsic::annotation;
    if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return
Intrinsic::arm_neon_vabals;
...

There has to be a more efficient way to do this. If nothing else, the
first 6 characters of that memcmp are always equal, and for groups of
intrinsics like llvm.arm.neon.v*, a trie-like search would be better.
llvm/ADT/Trie.h doesn't quite do what this needs (no prefix
searching), and it looks like it should be changed to use StringRefs
instead of std::strings during the search, but fixing and using it
here might be the right thing to do.

On Sat, Oct 17, 2009 at 3:48 AM, Nicolas Capens <nicolas at capens.net> wrote:
> Any takers? This patch improves on the previous one by making
> getIntrinsicID() inline.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



From nicolas at capens.net  Sat Oct 17 18:57:08 2009
From: nicolas at capens.net (Nicolas Capens)
Date: Sun, 18 Oct 2009 01:57:08 +0200
Subject: [LLVMdev] getIntrinsicID() optimization
In-Reply-To: <7980C3AD-1396-454A-A82D-70E012DD9CDA@apple.com>
References: <003d01ca4e5f$2fd1f8f0$8f75ead0$@net>
	<7980C3AD-1396-454A-A82D-70E012DD9CDA@apple.com>
Message-ID: <C28A4108BFF94824BA745C625C2B13A9@M65>

Hi Chris,

 

Function is currently 108 bytes large. Could 4 more bytes really be an
issue? Actually 2 should suffice. While I understand that some applications
value storage more than anything, many applications value compilation time
very highly. getIntrinsicID is called all over the place (isIntrinsic uses
it as well), and every single time it checks the function name. To me that
sounds a lot more dramatic than 2 bytes.

 

Anyway, using SubclassData could work. It's already being used for the
calling convention, which has values ranging from 0 to 68 (fitting in 7
bits), while intrinsic ID's would take 9 bits. So that would only just work.
However, the calling convention enums could be reordered to only take 3
bits.

 

I was wondering whether it would make sense to have an IntrinsicFunction
class, derived from Function. This way only the IntrinsicFunction would have
an intrinsicID field. I noticed that Function already has virtual methods so
getIntrinsicID could be another virtual method without adding any real
overhead. For Function it would simply return 0 while for IntrinsicFunction
it returns the intrinsicID field that was initialized in the constructor.

 

Cheers,

 

Nicolas

 

  _____  

From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Saturday, 17 October, 2009 22:54
To: Nicolas Capens
Cc: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] getIntrinsicID() optimization

 

 

On Oct 16, 2009, at 5:50 AM, Nicolas Capens wrote:





Hi all,

 

While profiling I discovered that the Function::getIntrinsicID() method is
called a lot, and every time it uses string comparison to recompute the ID
number. As far as I know the name of an intrinsic function doesn't change,
so the ID could be determined just once at Function construction time.

 

I've attached a patch that does this and it appears to work for the code I
tested it with. Could anyone look at potential caveats and if there are none
commit it?

 

Hi Nicolas,

 

Sorry for the delay.  I don't think that this is the right way to go.
Making Function larger is an extremely expensive thing to do.  There are use
cases in LLVM where apps load large modules lazily and stream in functions
on demand.  The way this works currently is that the function objects are
created eagerly, but their bodies are lazy.  Increasing hte size of function
can substantially penalize these cases.

 

Also, as Jeffrey points out, it is not safe with setName().

 

However, this would be a great thing to have.  Instead of adding a new
field, is there space in the "SubClassData" field in Value?

 

-Chris

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/aad14a53/attachment.html 

From vadve at illinois.edu  Sat Oct 17 19:27:11 2009
From: vadve at illinois.edu (Vikram S. Adve)
Date: Sat, 17 Oct 2009 19:27:11 -0500
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
Message-ID: <6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>


On Oct 15, 2009, at 10:45 AM, Chris Lattner wrote:

> Unfortunately, we found out at the last minute that Apple has a rule
> which prevents its engineers from giving video taped talks or
> distributing slides.  We will hold onto the video and slide assets in
> case this rule changes in the future.
>
> -Chris


Chris,

I hope you can pass my message along to the people at Apple who made  
this decision.
---

I want to request Apple to make an exception and release the videos  
and slides of presentations by Apple employees at the LLVM Developers'  
Meeting.  Several Apple employees now have a leadership role in the  
LLVM community, although LLVM remains a widely used open source  
software project.  Their presentations at the LLVM developers' meeting  
are an important component of how we help support LLVM users.  The  
presentations clearly reveal no confidential Apple information; in  
fact, they were presented in front of a large number of external  
participants.  While we appreciate Apple's continued support of LLVM  
and of the Developers' Meeting, the goodwill generated is being  
undermined by this policy to withhold important technical information  
from other LLVM users, and for little benefit to Apple.

--Vikram Adve

----------------------------------------------------------------------
  VIKRAM S. ADVE
  Associate Professor, Computer Science       E-MAIL: vadve at cs.uiuc.edu
  Siebel Center for Computer Science           PHONE:    (217) 244-2016
  Univ. of Illinois at Urbana-Champaign          FAX:    (217) 244-6500
  201 N. Goodwin Ave.
  Urbana IL 61801-2302.                          http://llvm.org/~vadve
----------------------------------------------------------------------


From zhunansjtu at gmail.com  Sat Oct 17 21:19:29 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Sun, 18 Oct 2009 10:19:29 +0800
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
Message-ID: <1255832369.23327.10.camel@UIUC>

Hi,

I don't think just use gold-plugin even modified is enough for the task
of building a whole-program bc file.

When we want to build a whole-program bc file by a general solution(I
meant that we can use such a method for all kinds of build system),we
need not only a gold-plugin to do what llvm-ld does,but also some
mechanisms,not a simple trick to modify the env variables,to run
ar,ld,ranlib's llvm-counterparts when building.

A wrapper which can wraps cc1,ld,ar,ranlib may archieve it..

Nan





From jyasskin at google.com  Sat Oct 17 21:24:46 2009
From: jyasskin at google.com (Jeffrey Yasskin)
Date: Sat, 17 Oct 2009 19:24:46 -0700
Subject: [LLVMdev] getIntrinsicID() optimization, mark 2
In-Reply-To: <7F789AE2A937422F9DFBA0A6F45F1FE2@M65>
References: <003601ca4f17$4ea7c3a0$ebf74ae0$@net>
	<bb55930e0910171003j550a872fo32679537c26d148e@mail.gmail.com>
	<7F789AE2A937422F9DFBA0A6F45F1FE2@M65>
Message-ID: <bb55930e0910171924s72c9b49dva8bf63d3650af3df@mail.gmail.com>

Sorry, I should have said that you should add a test checking the
correct behavior. I don't really have an opinion on which behavior is
correct--I just assumed you didn't realize the behavior would change.

On Sat, Oct 17, 2009 at 4:08 PM, Nicolas Capens <nicolas at capens.net> wrote:
> Hi Jeffrey,
>
> Please correct me if I'm wrong, but I believe a test that checks for the old
> behavior would be pointless. I realize that my patch would return an
> unmatching intrinsicID when the function's name changes, but the real
> question we should ask is do we really want to be able to change the
> intrinsicID by changing the function's name?
>
> Also, the original Function constructor contains this code:
>
> // Ensure intrinsics have the right parameter attributes.
> if (unsigned IID = getIntrinsicID())
> ? ?setAttributes(Intrinsic::getAttributes(Intrinsic::ID(IID)));
>
> Note that if you hypothetically changed an intrinsic's name it's parameter
> attributes could potentially become invalid...
>
> It seems to me that intrinsic names were never intended to be changed in the
> first place. That sounds perfectly reasonable to me, although it should
> probably be documented somewhere. So unless there are tangible reasons why
> intrinsics should actually be allowed to change name I believe my patch is
> valid.
>
> Cheers,
>
> Nicolas
>
>
> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin at google.com]
> Sent: Saturday, 17 October, 2009 19:03
> To: Nicolas Capens
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] getIntrinsicID() optimization, mark 2
>
> It is possible to change the name of a Function with Value::setName,
> so this patch _could_ cause incorrect answers. You should add a test
> that calls setName("intrinsic.name") to make sure this keeps working,
> regardless of where this patch goes. ?You might be able to catch such
> events in the ValueSymbolTable and update the intrinsic ID, but I
> can't find an obvious place to put that code.
>
> I also noticed that getIntrinsicID (implemented in Intrinsics.gen) is
> a switch statement on the first letter of the intrinsic name plus a
> long series of
> ? ?if (Len == 16 && !memcmp(Name, "llvm.alpha.umulh", 16)) return
> Intrinsic::alpha_umulh;
> ? ?if (Len > 15 && !memcmp(Name, "llvm.annotation.", 16)) return
> Intrinsic::annotation;
> ? ?if (Len > 20 && !memcmp(Name, "llvm.arm.neon.vabals.", 21)) return
> Intrinsic::arm_neon_vabals;
> ...
>
> There has to be a more efficient way to do this. If nothing else, the
> first 6 characters of that memcmp are always equal, and for groups of
> intrinsics like llvm.arm.neon.v*, a trie-like search would be better.
> llvm/ADT/Trie.h doesn't quite do what this needs (no prefix
> searching), and it looks like it should be changed to use StringRefs
> instead of std::strings during the search, but fixing and using it
> here might be the right thing to do.
>
> On Sat, Oct 17, 2009 at 3:48 AM, Nicolas Capens <nicolas at capens.net> wrote:
>> Any takers? This patch improves on the previous one by making
>> getIntrinsicID() inline.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>


From nicholas at mxc.ca  Sat Oct 17 21:35:57 2009
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 17 Oct 2009 19:35:57 -0700
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <1255832369.23327.10.camel@UIUC>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC>
Message-ID: <4ADA7F0D.4050107@mxc.ca>

zhunan wrote:
> Hi,
> 
> I don't think just use gold-plugin even modified is enough for the task
> of building a whole-program bc file.
> 
> When we want to build a whole-program bc file by a general solution(I
> meant that we can use such a method for all kinds of build system),we
> need not only a gold-plugin to do what llvm-ld does,but also some
> mechanisms,not a simple trick to modify the env variables,to run
> ar,ld,ranlib's llvm-counterparts when building.

Binutils 2.20 supports plugins and 'ar' and 'nm' will work with the gold 
plugin. Not sure about ranlib.

Nick


From zhunansjtu at gmail.com  Sat Oct 17 21:40:19 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Sun, 18 Oct 2009 10:40:19 +0800
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <4ADA7F0D.4050107@mxc.ca>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC>  <4ADA7F0D.4050107@mxc.ca>
Message-ID: <1255833619.23327.15.camel@UIUC>

Thank you for the reply,but I meant that when we building,we can not use
the native tools such ar and as to process the llvm files,we must have
the ability to call llvm-ar and llvm-as instead of the native ones.



? 2009-10-17?? 19:35 -0700?Nick Lewycky???
> zhunan wrote:
> > Hi,
> > 
> > I don't think just use gold-plugin even modified is enough for the task
> > of building a whole-program bc file.
> > 
> > When we want to build a whole-program bc file by a general solution(I
> > meant that we can use such a method for all kinds of build system),we
> > need not only a gold-plugin to do what llvm-ld does,but also some
> > mechanisms,not a simple trick to modify the env variables,to run
> > ar,ld,ranlib's llvm-counterparts when building.
> 
> Binutils 2.20 supports plugins and 'ar' and 'nm' will work with the gold 
> plugin. Not sure about ranlib.
> 
> Nick
> 


From wmoss at mac.com  Sat Oct 17 23:27:02 2009
From: wmoss at mac.com (William Moss)
Date: Sun, 18 Oct 2009 00:27:02 -0400
Subject: [LLVMdev]  [cfe-dev] Developer meeting videos up
Message-ID: <651ECA43-5690-489A-9D14-77DB47409892@mac.com>

At least with WWDC videos and materials that Apple also keeps out of  
the public eye, there's a way for people who have agreed to Apple's  
NDA to buy access to the materials if it's important enough to spend  
the money.

But this policy is prohibiting access by any means (including NDA's)  
which seems to make an even more restrictive situation than the super- 
secret WWDC pre-release materials.

Someone clearly hasn't thought this policy through.

William

From clattner at apple.com  Sat Oct 17 23:30:03 2009
From: clattner at apple.com (Chris Lattner)
Date: Sat, 17 Oct 2009 21:30:03 -0700
Subject: [LLVMdev] getIntrinsicID() optimization
In-Reply-To: <C28A4108BFF94824BA745C625C2B13A9@M65>
References: <003d01ca4e5f$2fd1f8f0$8f75ead0$@net>
	<7980C3AD-1396-454A-A82D-70E012DD9CDA@apple.com>
	<C28A4108BFF94824BA745C625C2B13A9@M65>
Message-ID: <C912FB57-E16E-4BE5-AA0D-4C37F1FE2FB5@apple.com>

On Oct 17, 2009, at 4:57 PM, Nicolas Capens wrote:

> Hi Chris,
>
> Function is currently 108 bytes large. Could 4 more bytes really be  
> an issue?

Yes.  :)

> Actually 2 should suffice. While I understand that some applications  
> value storage more than anything, many applications value  
> compilation time very highly. getIntrinsicID is called all over the  
> place (isIntrinsic uses it as well), and every single time it checks  
> the function name. To me that sounds a lot more dramatic than 2 bytes?
>
> Anyway, using SubclassData could work. It?s already being used for  
> the calling convention, which has values ranging from 0 to 68  
> (fitting in 7 bits), while intrinsic ID?s would take 9 bits. So that  
> would only just work. However, the calling convention enums could be  
> reordered to only take 3 bits.

I think that fitting it into SubclassData would be best.

> I was wondering whether it would make sense to have an  
> IntrinsicFunction class, derived from Function. This way only the  
> IntrinsicFunction would have an intrinsicID field. I noticed that  
> Function already has virtual methods so getIntrinsicID could be  
> another virtual method without adding any real overhead. For  
> Function it would simply return 0 while for IntrinsicFunction it  
> returns the intrinsicID field that was initialized in the constructor.


It would be fine to have a stateless IntrinsicFunction class (Similar  
to IntrinsicInst) but it wouldn't work to add state there.  We do need  
setName etc to work.  The bytecode and .ll parsers have to play games  
when autoupgrading old .ll files, and we want the IR manipulation  
methods to be simple and consistent where possible.  I completely  
agree that making getIntrinsicID() fast is a worthwhile goal, lets  
just not lose anything else in the process :)

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091017/50a16e99/attachment-0001.html 

From meurant.olivier at gmail.com  Sun Oct 18 15:25:36 2009
From: meurant.olivier at gmail.com (Olivier Meurant)
Date: Sun, 18 Oct 2009 22:25:36 +0200
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>

Hi Tanya,

glad to see that 2.6 release is coming. :)

After doing some testing with valgrind on this release, I have find a little
"undefined memory" error in DefaultJITMemoryManager related to the
PoisonMemory field.
This bug has been corrected in trunk with revision r80192.

Attached is a patch which cleanly apply same correction on the release-2.6
branch.

Thanks,
Olivier.


On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com> wrote:

> LLVMers,
> 2.6 pre-release2 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> If you have time, I'd appreciate anyone who can help test the release.
>
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects
> directory (name it llvm-test or test-suite). Choose to use a pre-compiled
> llvm-gcc or re-compile it yourself.
> 2) Run make check, report any failures (FAIL or unexpected pass). Note that
> you need to reconfigure llvm with llvm-gcc in your path or with
> --with-llvmgccdir
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> To test clang:
> 1) Compile llvm and clang from source.
> 2) Run make check for llvm.
> 3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures or
> unexpected passes)
>
> When reporting your results, please provide details on what platform you
> compiled on, and how
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>
> *Please COMPLETE ALL TESTING BY 5pm PDT on October 21st! *
> Thanks, Tanya Lattner
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/1f62abf2/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: release_2.6.patch
Type: text/x-patch
Size: 834 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/1f62abf2/attachment.bin 

From oleg77 at gmail.com  Sun Oct 18 15:46:44 2009
From: oleg77 at gmail.com (Oleg Knut)
Date: Sun, 18 Oct 2009 23:46:44 +0300
Subject: [LLVMdev] JIT and security
Message-ID: <C2CD11B4-6A43-43AF-93A2-E92E45AF9A28@gmail.com>

Hello,

I'm writing JIT compiler that will run a third party code. My goal is  
to build it with security layer that will allow me to prevent some  
basic operation that possibly can harm JIT application host computer.

Maybe some of you can guide me on how to do following operations:
  1) prevent system calls
  2) memory allocation management (set some limits that can't be used  
by JIT)
  3) CPU power limiting

I have a guess on how to prevent system calls or some known function  
calls by parsing IR and picking up functions calls that maybe  
unwanted. Another way is to check list of functions in object model.  
Maybe there is already implemented mechanism like that. So, anyone  
could give me a clue.

About RAM and CPU management I have no idea how to do that.

Ideally my JIT compiler have to become a BlackBox, that hosting party  
can configure to his needs.

I hope I can find some help here. That would be great!

Thank you for your time,
Oleg.

From nicolas.geoffray at lip6.fr  Sun Oct 18 16:11:13 2009
From: nicolas.geoffray at lip6.fr (Nicolas Geoffray)
Date: Sun, 18 Oct 2009 23:11:13 +0200
Subject: [LLVMdev] Build errors for vmkit
In-Reply-To: <4AD9FBE3.7000105@princeton.edu>
References: <4AD9FBE3.7000105@princeton.edu>
Message-ID: <20091018231113.84241w9qngrg5hno@webmail.lip6.fr>

Dear Michael,

The symbols that are said undefined by the compiler live in  
libAllocator.a. That file should be in Release/lib/, do you have it?  
It is possible that the compiler has linking order problems. What is  
the version of your gcc?

You can try changing the link order of the make command by editing  
tools/vmkit/Makefile.

Also, you should know that the GC of vmkit does not work on a 64bit  
system, so if you need the GC, you should try to emulate a 32bit system.

Let me know how that worked for you.

Nicolas


Quoting Michael Wu <mmwu at princeton.edu>:

> Hi,
>
>     I can't seem to get VMKit to compile correctly. I'm on a 64 bit
> Jaunty system. I compiled llvm and llvm-gcc from the subversion source
> no problem, but when I try to compile VMKit I get some issue with
> GCAllocator:
>
> /home/mmwu/Download/llvm$ ./configure
> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1
> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install
>
> ...
>
> /home/mmwu/Download/$ sudo apt-get install classpath
>
> ...
>
> /home/mmwu/Download/vmkit$ ./configure
> --with-llvmsrc=/home/mmwu/Download/llvm
> --with-llvmobj=/home/mmwu/Download/llvm
> --with-gnu-classpath-glibj=/usr/share/classpath/glibj.zip
> --with-gnu-classpath-libs=/usr/lib/classpath
> /home/mmwu/Download/vmkit$ make ENABLE_OPTIMIZED=1
>
> make[2]: Entering directory `/home/mmwu/Download/vmkit/tools/vmkit'
> llvm[2]: Linking Release executable vmkit (without symbols)
> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
> function `mvm::Collector::destroy()':
> gcinit.cpp:(.text+0x34): undefined reference to
> `GCAllocator::~GCAllocator()'
> gcinit.cpp:(.text+0x3c): undefined reference to `GCAllocator::operator
> delete(void*)'
> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
> function `mvm::Collector::initialise()':
> gcinit.cpp:(.text+0x216): undefined reference to `GCAllocator::operator
> new(unsigned long)'
> gcinit.cpp:(.text+0x221): undefined reference to
> `GCAllocator::GCAllocator()'
> gcinit.cpp:(.text+0x2d5): undefined reference to `GCAllocator::operator
> delete(void*)'
> collect2: ld returned 1 exit status
> make[2]: *** [/home/mmwu/Download/vmkit/Release/bin/vmkit] Error 1
> make[2]: Leaving directory `/home/mmwu/Download/vmkit/tools/vmkit'
> make[1]: *** [vmkit/.makeall] Error 2
> make[1]: Leaving directory `/home/mmwu/Download/vmkit/tools'
> make: *** [all] Error 1
>
> I would really appreciate any help I could get.
>
> Thanks,
> Michael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>





From daniel at zuster.org  Sun Oct 18 17:27:25 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 18 Oct 2009 15:27:25 -0700
Subject: [LLVMdev] Call For Buildbot Machines
Message-ID: <6a8523d60910181527h3cd7458eodad2f6dd30ea28b8@mail.gmail.com>

Hello LLVMers,

I'd really appreciate it if interested parties could contribute some
machine power to run the public buildbot.

In particular, we could really use at least one of the following:
 1. A fast Windows machine.
 2. A fast Linux i386 machine (two, ideally).
 3. Another fast Linux x86_64 machine (currently there is no Linux
llvm-gcc x86_64 self hosting build, for example).

If you, your company, or someone you know has spare cycles to
contribute, please email me privately. I'll take what I can get, but
ideally the resources would be:
 1. Fast and well-provisioned with memory.
 2. Stay up and available for extended periods.
 3. Someone is available to monitor the machine if it fails, or help
diagnose machine-specific failures.

Cheers,
 - Daniel

From mmwu at Princeton.EDU  Sun Oct 18 19:36:01 2009
From: mmwu at Princeton.EDU (Michael Wu)
Date: Sun, 18 Oct 2009 20:36:01 -0400
Subject: [LLVMdev] Build errors for vmkit
In-Reply-To: <20091018231113.84241w9qngrg5hno@webmail.lip6.fr>
References: <4AD9FBE3.7000105@princeton.edu>
	<20091018231113.84241w9qngrg5hno@webmail.lip6.fr>
Message-ID: <4ADBB471.7080102@princeton.edu>

Hi,

    Yes, I do have those files under Release/lib

I have gcc 4.3.2 (see output)

gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--enable-mpfr --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)

Do I definitely need the GC of vmkit to get Java programs to run 
successfully? If so I'll put a chroot jail 32 bit distribution on my 
machine.

How would I go about changing the link order?

Michael

Nicolas Geoffray wrote:
> Dear Michael,
>
> The symbols that are said undefined by the compiler live in  
> libAllocator.a. That file should be in Release/lib/, do you have it?  
> It is possible that the compiler has linking order problems. What is  
> the version of your gcc?
>
> You can try changing the link order of the make command by editing  
> tools/vmkit/Makefile.
>
> Also, you should know that the GC of vmkit does not work on a 64bit  
> system, so if you need the GC, you should try to emulate a 32bit system.
>
> Let me know how that worked for you.
>
> Nicolas
>
>
> Quoting Michael Wu <mmwu at princeton.edu>:
>
>   
>> Hi,
>>
>>     I can't seem to get VMKit to compile correctly. I'm on a 64 bit
>> Jaunty system. I compiled llvm and llvm-gcc from the subversion source
>> no problem, but when I try to compile VMKit I get some issue with
>> GCAllocator:
>>
>> /home/mmwu/Download/llvm$ ./configure
>> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1
>> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install
>>
>> ...
>>
>> /home/mmwu/Download/$ sudo apt-get install classpath
>>
>> ...
>>
>> /home/mmwu/Download/vmkit$ ./configure
>> --with-llvmsrc=/home/mmwu/Download/llvm
>> --with-llvmobj=/home/mmwu/Download/llvm
>> --with-gnu-classpath-glibj=/usr/share/classpath/glibj.zip
>> --with-gnu-classpath-libs=/usr/lib/classpath
>> /home/mmwu/Download/vmkit$ make ENABLE_OPTIMIZED=1
>>
>> make[2]: Entering directory `/home/mmwu/Download/vmkit/tools/vmkit'
>> llvm[2]: Linking Release executable vmkit (without symbols)
>> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
>> function `mvm::Collector::destroy()':
>> gcinit.cpp:(.text+0x34): undefined reference to
>> `GCAllocator::~GCAllocator()'
>> gcinit.cpp:(.text+0x3c): undefined reference to `GCAllocator::operator
>> delete(void*)'
>> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
>> function `mvm::Collector::initialise()':
>> gcinit.cpp:(.text+0x216): undefined reference to `GCAllocator::operator
>> new(unsigned long)'
>> gcinit.cpp:(.text+0x221): undefined reference to
>> `GCAllocator::GCAllocator()'
>> gcinit.cpp:(.text+0x2d5): undefined reference to `GCAllocator::operator
>> delete(void*)'
>> collect2: ld returned 1 exit status
>> make[2]: *** [/home/mmwu/Download/vmkit/Release/bin/vmkit] Error 1
>> make[2]: Leaving directory `/home/mmwu/Download/vmkit/tools/vmkit'
>> make[1]: *** [vmkit/.makeall] Error 2
>> make[1]: Leaving directory `/home/mmwu/Download/vmkit/tools'
>> make: *** [all] Error 1
>>
>> I would really appreciate any help I could get.
>>
>> Thanks,
>> Michael
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   

From ericbrunstad at mac.com  Sun Oct 18 20:32:04 2009
From: ericbrunstad at mac.com (Eric Brunstad)
Date: Sun, 18 Oct 2009 21:32:04 -0400
Subject: [LLVMdev] Objective-C code in lli
Message-ID: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>

Hi,

Is it possible to run Objective-C code in lli?  lli does not seem to  
want to load Foundation.framework.

Please see below.

Thanks,

Eric Brunstad

#import <Foundation/Foundation.h>

int main(int argc, char *argv[])
{
	NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
	NSLog(@"test!");
	[pool drain];
	return EXIT_SUCCESS;
}

cmu-351714:llvm-2.5 ericbrunstad$ /Users/ericbrunstad/Downloads/ 
llvm-2.5/Release/bin/lli -force-interpreter=true -stats  /Users/ 
ericbrunstad/Desktop/test/test.o -load=/System/Library/Frameworks/ 
Foundation.framework/Foundation

Could not resolve external global address:  
__CFConstantStringClassReference
0   lli               0x0000000100687556 (anonymous  
namespace)::SignalHandler(int) + 470
1   libSystem.B.dylib 0x00007fff83ee10aa _sigtramp + 26
2   libSystem.B.dylib 0x0000000100a0b4ba _sigtramp + 2092082218
3   lli               0x00000001001e8374  
llvm::ExecutionEngine::emitGlobals() + 6164
4   lli               0x00000001001dbd69 llvm::Interpreter::Interpreter 
(llvm::ModuleProvider*) + 185
5   lli               0x00000001001dbdd8 llvm::Interpreter::create 
(llvm::ModuleProvider*, std::string*, bool) + 56
6   lli               0x0000000100010803 main + 243
7   lli               0x00000001000106e8 start + 52

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/7e373b0c/attachment.html 

From samuraileumas at yahoo.com  Sun Oct 18 21:27:50 2009
From: samuraileumas at yahoo.com (Samuel Crow)
Date: Sun, 18 Oct 2009 19:27:50 -0700 (PDT)
Subject: [LLVMdev] Objective-C code in lli
In-Reply-To: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
References: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
Message-ID: <408778.43213.qm@web62004.mail.re1.yahoo.com>

Hi Eric,

You're forcing the interpreter.  That is less compatible than the JIT since fewer people are interested in maintaining the interpreter.  I'm not sure how well it interprets since there has been some work done on it.  Try leaving that option out.  Also, make sure that Clang has all of the proper entries set for emitting LLVM bitcode rather than object code.

I hope this helps,

--Sam


>
>From: Eric Brunstad <ericbrunstad at mac.com>
>To: llvmdev at cs.uiuc.edu
>Sent: Sun, October 18, 2009 8:32:04 PM
>Subject: [LLVMdev] Objective-C code in lli
>
>Hi,
>
>
>Is it possible to run Objective-C code in lli?  lli does not seem to want to load Foundation.framework.
>
>
>Please see below.
>
>
>Thanks,
>
>
>Eric Brunstad
>
>
>#import <Foundation/Foundation.h>
>
>
>int main(int argc, char *argv[])
>{
>NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>NSLog(@"test!");
>[pool drain];
>return EXIT_SUCCESS;
>}
>
>
>cmu-351714:llvm-2.5 ericbrunstad$ /Users/ericbrunstad/Downloads/llvm-2.5/Release/bin/lli -force-interpreter=true -stats  /Users/ericbrunstad/Desktop/test/test.o -load=/System/Library/Frameworks/Foundation.framework/Foundation
>
>
>
>Could not resolve external global address: __CFConstantStringClassReference
>0   lli               0x0000000100687556 (anonymous namespace)::SignalHandler(int) + 470
>1   libSystem.B.dylib 0x00007fff83ee10aa _sigtramp + 26
>2   libSystem.B.dylib 0x0000000100a0b4ba _sigtramp + 2092082218
>3   lli               0x00000001001e8374 llvm::ExecutionEngine::emitGlobals() + 6164
>4   lli               0x00000001001dbd69 llvm::Interpreter::Interpreter(llvm::ModuleProvider*) + 185
>5   lli               0x00000001001dbdd8 llvm::Interpreter::create(llvm::ModuleProvider*, std::string*, bool) + 56
>6   lli               0x0000000100010803 main + 243
>7   lli               0x00000001000106e8 start + 52
>
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/1c59a4a1/attachment.html 

From daniel at zuster.org  Sun Oct 18 21:49:08 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 18 Oct 2009 19:49:08 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
Message-ID: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>

Hi all,

As you may or may not have noticed, I have gradually been replacing
the testing infrastructure in LLVM. Most of this work is moving LLVM
and Clang to share a single testing tool, 'lit'. See:
  http://llvm.org/cmds/lit.html
for documentation on the tool itself.

If you haven't already tried it, please consider switch to 'make
check-lit' as an alternative to 'make check'. If it doesn't work for
you, or you find it doesn't do something DejaGNU did and you like,
please let me know. My eventual plan is to move to lit entirely and
drop DejaGNU support, so consider yourself warned.

A couple key points about 'make check-lit':
 1. It runs the unittests as well, there is no separate 'make
unittests' step. If you like, there is also a 'make check-all' which
will also run the Clang tests at the same time if it happens to be
checked out in the standard location (tools/clang).
 2. The public buildbots have switched to it. It shouldn't happen, but
if you do find a discrepancy between DejaGNU and lit, let me know.

If you aren't already familiar with it, here are some of the advantages of lit:
 1. It is portable. It already is being used on the Windows buildbot
for Clang, and almost all of our tests "just work".
 2. It uses multiple threads to test. While it doesn't yet scale quite
as well as I would like, switching the Linux x86_64 buildbot to it
dropped its cycle time by over 30% (just because running the tests got
about 3x faster).
 3. I've tried hard to make it easy to use, and will keep working in
this direction. Eventually I want to replace the TestRunner scripts as
well so that all that is needed to run a single test is 'lit
path/to/the/test'. I also would like to improve the output for
failures to be more informative (particularly when run via buildbot).

See http://llvm.org/PR5217 for my TODO list before dropping DejaGNU,
feel free to add comments, requests, or blocking bugs to that one.

 - Daniel

From vgrover528 at gmail.com  Sun Oct 18 21:51:32 2009
From: vgrover528 at gmail.com (Vinod Grover)
Date: Sun, 18 Oct 2009 19:51:32 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
Message-ID: <35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>

I too am disappointed that not all talk slides are posted. To me it speaks
poorly of the whole meeting since there were parallel sessions and not
everyone could attend in person all the sessions they wanted to. The slides
are, I thought, meant to be like the "proceedings" and If I recall some of
the Apple slides are present from previous years but not this year.

Vinod


On Sat, Oct 17, 2009 at 5:27 PM, Vikram S. Adve <vadve at illinois.edu> wrote:

>
> On Oct 15, 2009, at 10:45 AM, Chris Lattner wrote:
>
> > Unfortunately, we found out at the last minute that Apple has a rule
> > which prevents its engineers from giving video taped talks or
> > distributing slides.  We will hold onto the video and slide assets in
> > case this rule changes in the future.
> >
> > -Chris
>
>
> Chris,
>
> I hope you can pass my message along to the people at Apple who made
> this decision.
> ---
>
> I want to request Apple to make an exception and release the videos
> and slides of presentations by Apple employees at the LLVM Developers'
> Meeting.  Several Apple employees now have a leadership role in the
> LLVM community, although LLVM remains a widely used open source
> software project.  Their presentations at the LLVM developers' meeting
> are an important component of how we help support LLVM users.  The
> presentations clearly reveal no confidential Apple information; in
> fact, they were presented in front of a large number of external
> participants.  While we appreciate Apple's continued support of LLVM
> and of the Developers' Meeting, the goodwill generated is being
> undermined by this policy to withhold important technical information
> from other LLVM users, and for little benefit to Apple.
>
> --Vikram Adve
>
> ----------------------------------------------------------------------
>   VIKRAM S. ADVE
>  Associate Professor, Computer Science       E-MAIL: vadve at cs.uiuc.edu
>  Siebel Center for Computer Science           PHONE:    (217) 244-2016
>  Univ. of Illinois at Urbana-Champaign          FAX:    (217) 244-6500
>  201 N. Goodwin Ave.
>  Urbana IL 61801-2302.                          http://llvm.org/~vadve<http://llvm.org/%7Evadve>
> ----------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/1058b803/attachment.html 

From viridia at gmail.com  Sun Oct 18 21:54:27 2009
From: viridia at gmail.com (Talin)
Date: Sun, 18 Oct 2009 19:54:27 -0700
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
Message-ID: <4ADBD4E3.5090106@gmail.com>

So I wasn't able to attend the developer meeting this year, even though 
I had signed up for it. This was a big disappointment to me, 
particularly because I had hoped to get some hands-on assistance for 
some unsolved problems that I have been struggling with for the last six 
months or so. Unfortunately, some of these problems aren't easily 
reducible to a simple test case which I can send as an email attachment, 
and of the ones I do post on this list, about half go unanswered (not 
that I'm casting blame, I know how these things go.) In any case, I 
figured I would simply put those problems aside and then bring my laptop 
to the developer meeting and possibly get one or more of the LLVM 
experts to spend some time with me. And then I had to go and miss the 
meeting. :(

So I kind of wonder if there are possibly other opportunities for 
face-to-face interaction with the LLVM folks, on a smaller but more 
frequent basis than the annual developer meeting. Something like a user 
group? :)

-- Talin


From ofv at wanadoo.es  Sun Oct 18 22:04:57 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Mon, 19 Oct 2009 05:04:57 +0200
Subject: [LLVMdev] RFC: Dropping DejaGNU
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
Message-ID: <87fx9gxew6.fsf@telefonica.net>

Daniel Dunbar <daniel at zuster.org> writes:

[snip]

>  1. It is portable. It already is being used on the Windows buildbot
> for Clang, and almost all of our tests "just work".

Nice.

Thanks Daniel!

-- 
?scar


From clattner at apple.com  Sun Oct 18 22:54:58 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 18 Oct 2009 20:54:58 -0700
Subject: [LLVMdev] Opportunities for meeting more frequently than once
	a	year?
In-Reply-To: <4ADBD4E3.5090106@gmail.com>
References: <4ADBD4E3.5090106@gmail.com>
Message-ID: <14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>


On Oct 18, 2009, at 7:54 PM, Talin wrote:

> So I wasn't able to attend the developer meeting this year, even  
> though
> I had signed up for it. This was a big disappointment to me,
> particularly because I had hoped to get some hands-on assistance for
> some unsolved problems that I have been struggling with for the last  
> six
> months or so. Unfortunately, some of these problems aren't easily
> reducible to a simple test case which I can send as an email  
> attachment,
> and of the ones I do post on this list, about half go unanswered (not
> that I'm casting blame, I know how these things go.) In any case, I
> figured I would simply put those problems aside and then bring my  
> laptop
> to the developer meeting and possibly get one or more of the LLVM
> experts to spend some time with me. And then I had to go and miss the
> meeting. :(
>
> So I kind of wonder if there are possibly other opportunities for
> face-to-face interaction with the LLVM folks, on a smaller but more
> frequent basis than the annual developer meeting. Something like a  
> user
> group? :)

Sure, sounds fun.  We just lack an organizer.  If you make it happen,  
I'm pretty sure people will come :)

-Chris


From clattner at apple.com  Sun Oct 18 23:00:06 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 18 Oct 2009 21:00:06 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
Message-ID: <227A61F5-F125-4617-8022-214DAA084AF3@apple.com>


On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote:

> Hi all,
>
> As you may or may not have noticed, I have gradually been replacing
> the testing infrastructure in LLVM. Most of this work is moving LLVM
> and Clang to share a single testing tool, 'lit'. See:
>  http://llvm.org/cmds/lit.html
> for documentation on the tool itself.
>
> If you haven't already tried it, please consider switch to 'make
> check-lit' as an alternative to 'make check'. If it doesn't work for
> you, or you find it doesn't do something DejaGNU did and you like,
> please let me know. My eventual plan is to move to lit entirely and
> drop DejaGNU support, so consider yourself warned.

This is great work Daniel,

One question: Why not switch 'make check' to default to lit and offer  
'make check-dejagnu' as a workaround.  That forces adoption :)

-Chris

>
> A couple key points about 'make check-lit':
> 1. It runs the unittests as well, there is no separate 'make
> unittests' step. If you like, there is also a 'make check-all' which
> will also run the Clang tests at the same time if it happens to be
> checked out in the standard location (tools/clang).
> 2. The public buildbots have switched to it. It shouldn't happen, but
> if you do find a discrepancy between DejaGNU and lit, let me know.
>
> If you aren't already familiar with it, here are some of the  
> advantages of lit:
> 1. It is portable. It already is being used on the Windows buildbot
> for Clang, and almost all of our tests "just work".
> 2. It uses multiple threads to test. While it doesn't yet scale quite
> as well as I would like, switching the Linux x86_64 buildbot to it
> dropped its cycle time by over 30% (just because running the tests got
> about 3x faster).
> 3. I've tried hard to make it easy to use, and will keep working in
> this direction. Eventually I want to replace the TestRunner scripts as
> well so that all that is needed to run a single test is 'lit
> path/to/the/test'. I also would like to improve the output for
> failures to be more informative (particularly when run via buildbot).
>
> See http://llvm.org/PR5217 for my TODO list before dropping DejaGNU,
> feel free to add comments, requests, or blocking bugs to that one.
>
> - Daniel
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From clattner at apple.com  Sun Oct 18 23:01:39 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 18 Oct 2009 21:01:39 -0700
Subject: [LLVMdev] Objective-C code in lli
In-Reply-To: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
References: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
Message-ID: <C74EBDB4-4659-4561-809B-610CFCE72E15@apple.com>


On Oct 18, 2009, at 6:32 PM, Eric Brunstad wrote:

> Hi,
>
> Is it possible to run Objective-C code in lli?  lli does not seem to  
> want to load Foundation.framework.

It is definitely possible, but we're not there yet.  LLI would have to  
know about objective-c metadata to register it properly with the  
runtime.  This is important for things like classes etc.  This isn't  
conceptually hard, but noone has done it yet.

-Chris

>
> Please see below.
>
> Thanks,
>
> Eric Brunstad
>
> #import <Foundation/Foundation.h>
>
> int main(int argc, char *argv[])
> {
> 	NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> 	NSLog(@"test!");
> 	[pool drain];
> 	return EXIT_SUCCESS;
> }
>
> cmu-351714:llvm-2.5 ericbrunstad$ /Users/ericbrunstad/Downloads/ 
> llvm-2.5/Release/bin/lli -force-interpreter=true -stats  /Users/ 
> ericbrunstad/Desktop/test/test.o -load=/System/Library/Frameworks/ 
> Foundation.framework/Foundation
>
> Could not resolve external global address:  
> __CFConstantStringClassReference
> 0   lli               0x0000000100687556 (anonymous  
> namespace)::SignalHandler(int) + 470
> 1   libSystem.B.dylib 0x00007fff83ee10aa _sigtramp + 26
> 2   libSystem.B.dylib 0x0000000100a0b4ba _sigtramp + 2092082218
> 3   lli               0x00000001001e8374  
> llvm::ExecutionEngine::emitGlobals() + 6164
> 4   lli               0x00000001001dbd69  
> llvm::Interpreter::Interpreter(llvm::ModuleProvider*) + 185
> 5   lli               0x00000001001dbdd8 llvm::Interpreter::create 
> (llvm::ModuleProvider*, std::string*, bool) + 56
> 6   lli               0x0000000100010803 main + 243
> 7   lli               0x00000001000106e8 start + 52
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/cbbb534d/attachment.html 

From clattner at apple.com  Sun Oct 18 23:06:48 2009
From: clattner at apple.com (Chris Lattner)
Date: Sun, 18 Oct 2009 21:06:48 -0700
Subject: [LLVMdev] JIT and security
In-Reply-To: <C2CD11B4-6A43-43AF-93A2-E92E45AF9A28@gmail.com>
References: <C2CD11B4-6A43-43AF-93A2-E92E45AF9A28@gmail.com>
Message-ID: <0C2CF2C3-1A7F-4ED3-9343-73B786DBD552@apple.com>


On Oct 18, 2009, at 1:46 PM, Oleg Knut wrote:

> Hello,
>
> I'm writing JIT compiler that will run a third party code. My goal is
> to build it with security layer that will allow me to prevent some
> basic operation that possibly can harm JIT application host computer.
>
> Maybe some of you can guide me on how to do following operations:
>  1) prevent system calls
>  2) memory allocation management (set some limits that can't be used
> by JIT)
>  3) CPU power limiting
>
> I have a guess on how to prevent system calls or some known function
> calls by parsing IR and picking up functions calls that maybe
> unwanted. Another way is to check list of functions in object model.
> Maybe there is already implemented mechanism like that. So, anyone
> could give me a clue.

Hi Oleg,

I don't think that a JIT has anything to do with this.  These are all  
properties of the code running in the JIT (e.g. C, Java, etc).  If you  
can solve these (hard!) problems in a statically compiled language,  
the solutions would translate over directly.

-Chris

>
> About RAM and CPU management I have no idea how to do that.
>
> Ideally my JIT compiler have to become a BlackBox, that hosting party
> can configure to his needs.
>
> I hope I can find some help here. That would be great!
>
> Thank you for your time,
> Oleg.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From lattner at apple.com  Sun Oct 18 23:12:13 2009
From: lattner at apple.com (Tanya Lattner)
Date: Sun, 18 Oct 2009 21:12:13 -0700
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<549cee610910181325v6cd09955o15c2219afbed8a44@mail.gmail.com>
Message-ID: <44BF199D-5F43-4104-9482-27A994027FE2@apple.com>

Olivier,

Thanks for testing 2.6!

I'm glad this is fixed in trunk, but it will not  be applied to 2.6 at  
this stage in the release process.

Thanks,
Tanya

On Oct 18, 2009, at 1:25 PM, Olivier Meurant wrote:

> Hi Tanya,
>
> glad to see that 2.6 release is coming. :)
>
> After doing some testing with valgrind on this release, I have find  
> a little "undefined memory" error in DefaultJITMemoryManager related  
> to the PoisonMemory field.
> This bug has been corrected in trunk with revision r80192.
>
> Attached is a patch which cleanly apply same correction on the  
> release-2.6 branch.
>
> Thanks,
> Olivier.
>
>
> On Sat, Oct 17, 2009 at 8:51 PM, Tanya Lattner <lattner at apple.com>  
> wrote:
> LLVMers,
>
> 2.6 pre-release2 is ready to be tested by the community.
> http://llvm.org/prereleases/2.6/
>
> If you have time, I'd appreciate anyone who can help test the release.
>
>
> To test llvm-gcc:
> 1) Compile llvm from source and untar the llvm-test in the projects  
> directory (name it llvm-test or test-suite). Choose to use a pre- 
> compiled llvm-gcc or re-compile it yourself.
>
> 2) Run make check, report any failures (FAIL or unexpected pass).  
> Note that you need to reconfigure llvm with llvm-gcc in your path or  
> with --with-llvmgccdir
>
> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
>  To test clang:
> 1) Compile llvm and clang from source.
>
> 2) Run make check for llvm.
>  3) Run make  -C tools/clang-2.6 test VERBOSE=1 (report any failures  
> or unexpected passes)
>
>
> When reporting your results, please provide details on what platform  
> you compiled on, and how
>
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.
>
>  Please COMPLETE ALL TESTING BY 5pm PDT on October 21st!
> Thanks, Tanya Lattner
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> <release_2.6.patch>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/80203ffd/attachment.html 

From mmwu at Princeton.EDU  Sun Oct 18 23:55:34 2009
From: mmwu at Princeton.EDU (Michael Wu)
Date: Mon, 19 Oct 2009 00:55:34 -0400
Subject: [LLVMdev] Build errors for vmkit
In-Reply-To: <20091018231113.84241w9qngrg5hno@webmail.lip6.fr>
References: <4AD9FBE3.7000105@princeton.edu>
	<20091018231113.84241w9qngrg5hno@webmail.lip6.fr>
Message-ID: <4ADBF146.3050100@princeton.edu>

Worked great in a 32 bit build environment. Thanks a lot!

Michael

Nicolas Geoffray wrote:
> Dear Michael,
>
> The symbols that are said undefined by the compiler live in  
> libAllocator.a. That file should be in Release/lib/, do you have it?  
> It is possible that the compiler has linking order problems. What is  
> the version of your gcc?
>
> You can try changing the link order of the make command by editing  
> tools/vmkit/Makefile.
>
> Also, you should know that the GC of vmkit does not work on a 64bit  
> system, so if you need the GC, you should try to emulate a 32bit system.
>
> Let me know how that worked for you.
>
> Nicolas
>
>
> Quoting Michael Wu <mmwu at princeton.edu>:
>
>   
>> Hi,
>>
>>     I can't seem to get VMKit to compile correctly. I'm on a 64 bit
>> Jaunty system. I compiled llvm and llvm-gcc from the subversion source
>> no problem, but when I try to compile VMKit I get some issue with
>> GCAllocator:
>>
>> /home/mmwu/Download/llvm$ ./configure
>> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1
>> /home/mmwu/Download/llvm$ make ENABLE_OPTIMIZED=1 install
>>
>> ...
>>
>> /home/mmwu/Download/$ sudo apt-get install classpath
>>
>> ...
>>
>> /home/mmwu/Download/vmkit$ ./configure
>> --with-llvmsrc=/home/mmwu/Download/llvm
>> --with-llvmobj=/home/mmwu/Download/llvm
>> --with-gnu-classpath-glibj=/usr/share/classpath/glibj.zip
>> --with-gnu-classpath-libs=/usr/lib/classpath
>> /home/mmwu/Download/vmkit$ make ENABLE_OPTIMIZED=1
>>
>> make[2]: Entering directory `/home/mmwu/Download/vmkit/tools/vmkit'
>> llvm[2]: Linking Release executable vmkit (without symbols)
>> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
>> function `mvm::Collector::destroy()':
>> gcinit.cpp:(.text+0x34): undefined reference to
>> `GCAllocator::~GCAllocator()'
>> gcinit.cpp:(.text+0x3c): undefined reference to `GCAllocator::operator
>> delete(void*)'
>> /home/mmwu/Download/vmkit/Release/lib/libGCMmap2.a(gcinit.o): In
>> function `mvm::Collector::initialise()':
>> gcinit.cpp:(.text+0x216): undefined reference to `GCAllocator::operator
>> new(unsigned long)'
>> gcinit.cpp:(.text+0x221): undefined reference to
>> `GCAllocator::GCAllocator()'
>> gcinit.cpp:(.text+0x2d5): undefined reference to `GCAllocator::operator
>> delete(void*)'
>> collect2: ld returned 1 exit status
>> make[2]: *** [/home/mmwu/Download/vmkit/Release/bin/vmkit] Error 1
>> make[2]: Leaving directory `/home/mmwu/Download/vmkit/tools/vmkit'
>> make[1]: *** [vmkit/.makeall] Error 2
>> make[1]: Leaving directory `/home/mmwu/Download/vmkit/tools'
>> make: *** [all] Error 1
>>
>> I would really appreciate any help I could get.
>>
>> Thanks,
>> Michael
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>     
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From oleg77 at gmail.com  Mon Oct 19 00:33:41 2009
From: oleg77 at gmail.com (Oleg Knut)
Date: Mon, 19 Oct 2009 08:33:41 +0300
Subject: [LLVMdev] JIT and security
In-Reply-To: <0C2CF2C3-1A7F-4ED3-9343-73B786DBD552@apple.com>
References: <C2CD11B4-6A43-43AF-93A2-E92E45AF9A28@gmail.com>
	<0C2CF2C3-1A7F-4ED3-9343-73B786DBD552@apple.com>
Message-ID: <278bcd900910182233h199011c6ja61e25e792cbdfeb@mail.gmail.com>

Hi Chris,
Thank you for your quick answer!

I knew, that my question is not easy enough.

Maybe anyone know such projects or implementation examples on how to do a
memory and CPU management in C++? This could be a good start point for me.

Thanks,
Oleg.

2009/10/19 Chris Lattner <clattner at apple.com>

>
> On Oct 18, 2009, at 1:46 PM, Oleg Knut wrote:
>
>  Hello,
>>
>> I'm writing JIT compiler that will run a third party code. My goal is
>> to build it with security layer that will allow me to prevent some
>> basic operation that possibly can harm JIT application host computer.
>>
>> Maybe some of you can guide me on how to do following operations:
>>  1) prevent system calls
>>  2) memory allocation management (set some limits that can't be used
>> by JIT)
>>  3) CPU power limiting
>>
>> I have a guess on how to prevent system calls or some known function
>> calls by parsing IR and picking up functions calls that maybe
>> unwanted. Another way is to check list of functions in object model.
>> Maybe there is already implemented mechanism like that. So, anyone
>> could give me a clue.
>>
>
> Hi Oleg,
>
> I don't think that a JIT has anything to do with this.  These are all
> properties of the code running in the JIT (e.g. C, Java, etc).  If you can
> solve these (hard!) problems in a statically compiled language, the
> solutions would translate over directly.
>
> -Chris
>
>
>> About RAM and CPU management I have no idea how to do that.
>>
>> Ideally my JIT compiler have to become a BlackBox, that hosting party
>> can configure to his needs.
>>
>> I hope I can find some help here. That would be great!
>>
>> Thank you for your time,
>> Oleg.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/56532421/attachment.html 

From evan.cheng at apple.com  Mon Oct 19 00:58:19 2009
From: evan.cheng at apple.com (Evan Cheng)
Date: Sun, 18 Oct 2009 22:58:19 -0700
Subject: [LLVMdev] IMPORTANT: Post-regalloc scheduling and JIT
Message-ID: <F102840A-8878-428A-A56F-E5D15C9B69B2@apple.com>

Hi all,

I have turned on post- register allocation scheduling for x86 (Anton  
is investigating a problem on Linux, but it's *so far* working well on  
Darin). It's a very expensive codegen pass that can easily increase  
the codegen time by 10% or more. For this reason, I've added a new  
code generation optimization level CodeGenOpt::Less. If you are using  
the LLVM x86 JIT, you *should* initialize the with this optimization  
level to avoid running the pass (see  
LLVMTargetMachine::addPassesToEmitMachineCode).

Evan


From daniel at zuster.org  Mon Oct 19 01:44:55 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Sun, 18 Oct 2009 23:44:55 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <227A61F5-F125-4617-8022-214DAA084AF3@apple.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<227A61F5-F125-4617-8022-214DAA084AF3@apple.com>
Message-ID: <6a8523d60910182344l50038e54pfd781c90b910bdef@mail.gmail.com>

On Sun, Oct 18, 2009 at 9:00 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote:
>
>> Hi all,
>>
>> As you may or may not have noticed, I have gradually been replacing
>> the testing infrastructure in LLVM. Most of this work is moving LLVM
>> and Clang to share a single testing tool, 'lit'. See:
>> ?http://llvm.org/cmds/lit.html
>> for documentation on the tool itself.
>>
>> If you haven't already tried it, please consider switch to 'make
>> check-lit' as an alternative to 'make check'. If it doesn't work for
>> you, or you find it doesn't do something DejaGNU did and you like,
>> please let me know. My eventual plan is to move to lit entirely and
>> drop DejaGNU support, so consider yourself warned.
>
> This is great work Daniel,
>
> One question: Why not switch 'make check' to default to lit and offer 'make
> check-dejagnu' as a workaround. ?That forces adoption :)

I intend to as soon as it won't break anything. The sole blocker for
doing that is making sure it doesn't break the nightly testing
infrastructure.

 - Daniel

> -Chris
>
>>
>> A couple key points about 'make check-lit':
>> 1. It runs the unittests as well, there is no separate 'make
>> unittests' step. If you like, there is also a 'make check-all' which
>> will also run the Clang tests at the same time if it happens to be
>> checked out in the standard location (tools/clang).
>> 2. The public buildbots have switched to it. It shouldn't happen, but
>> if you do find a discrepancy between DejaGNU and lit, let me know.
>>
>> If you aren't already familiar with it, here are some of the advantages of
>> lit:
>> 1. It is portable. It already is being used on the Windows buildbot
>> for Clang, and almost all of our tests "just work".
>> 2. It uses multiple threads to test. While it doesn't yet scale quite
>> as well as I would like, switching the Linux x86_64 buildbot to it
>> dropped its cycle time by over 30% (just because running the tests got
>> about 3x faster).
>> 3. I've tried hard to make it easy to use, and will keep working in
>> this direction. Eventually I want to replace the TestRunner scripts as
>> well so that all that is needed to run a single test is 'lit
>> path/to/the/test'. I also would like to improve the output for
>> failures to be more informative (particularly when run via buildbot).
>>
>> See http://llvm.org/PR5217 for my TODO list before dropping DejaGNU,
>> feel free to add comments, requests, or blocking bugs to that one.
>>
>> - Daniel
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From viridia at gmail.com  Mon Oct 19 01:49:31 2009
From: viridia at gmail.com (Talin)
Date: Sun, 18 Oct 2009 23:49:31 -0700
Subject: [LLVMdev] Still can't get source-level debugging to work
Message-ID: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com>

I've been struggling with this for a while. I've gone back and reviewed all
the messages in this topic on the subject, and I still can't figure it out.
-- I'm disabling frame pointer elimination via "-disable-fp-elim"
-- I see debugging information in my .s file.
-- My command line for compiling the LLVM-generated looks like this:

    gcc -g -O0 -x assembler ReflectionTest.s -o ReflectionTest
-L/Users/talin/Projects/tart/build-eclipse/runtime -l runtime
-- here's what I see when I run 'dwarfdump':

> dwarfdump test/stdlib/ReflectionTest
----------------------------------------------------------------------
 File: test/stdlib/ReflectionTest (i386)
----------------------------------------------------------------------
.debug_info contents:
< EMPTY >


-- When I try to debug in gdb, it prints this:

warning: Could not find object file
"/var/folders/h6/h6He5G34EF8g9zpg3SNFF++++TI/-Tmp-//ccoTexQw.o" - no debug
information available for "ReflectionTest.tart".


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091018/a6785c33/attachment.html 

From anton at korobeynikov.info  Mon Oct 19 02:17:13 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 19 Oct 2009 11:17:13 +0400
Subject: [LLVMdev] Still can't get source-level debugging to work
In-Reply-To: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com>
References: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com>
Message-ID: <b087fca00910190017l67c08454j5848ab85e8824eff@mail.gmail.com>

> warning: Could not find object file
> "/var/folders/h6/h6He5G34EF8g9zpg3SNFF++++TI/-Tmp-//ccoTexQw.o" - no debug
> information available for "ReflectionTest.tart".
It seems you're on darwin, right? Then you need another build steps in
order to see dwarf stuff

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From viridia at gmail.com  Mon Oct 19 02:47:31 2009
From: viridia at gmail.com (Talin)
Date: Mon, 19 Oct 2009 00:47:31 -0700
Subject: [LLVMdev] Still can't get source-level debugging to work
In-Reply-To: <b087fca00910190017l67c08454j5848ab85e8824eff@mail.gmail.com>
References: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com> 
	<b087fca00910190017l67c08454j5848ab85e8824eff@mail.gmail.com>
Message-ID: <d1b71f830910190047h7e1e0e72u605a97bcd3098cdd@mail.gmail.com>

Yes I am on darwin.

On Mon, Oct 19, 2009 at 12:17 AM, Anton Korobeynikov <
anton at korobeynikov.info> wrote:

> > warning: Could not find object file
> > "/var/folders/h6/h6He5G34EF8g9zpg3SNFF++++TI/-Tmp-//ccoTexQw.o" - no
> debug
> > information available for "ReflectionTest.tart".
> It seems you're on darwin, right? Then you need another build steps in
> order to see dwarf stuff
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/3d616e6a/attachment.html 

From anton at korobeynikov.info  Mon Oct 19 02:52:14 2009
From: anton at korobeynikov.info (Anton Korobeynikov)
Date: Mon, 19 Oct 2009 11:52:14 +0400
Subject: [LLVMdev] Still can't get source-level debugging to work
In-Reply-To: <d1b71f830910190047h7e1e0e72u605a97bcd3098cdd@mail.gmail.com>
References: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com>
	<b087fca00910190017l67c08454j5848ab85e8824eff@mail.gmail.com>
	<d1b71f830910190047h7e1e0e72u605a97bcd3098cdd@mail.gmail.com>
Message-ID: <b087fca00910190052p4c5d03eud73fad5b0de09f06@mail.gmail.com>

> Yes I am on darwin.
I don't recall correctly, but there you cannot 'just' run gcc to get
all dwarf stuff into the binary. You will also need to do some extra
tool invocation (dsymutil?). Just pick some dummy c++ app, compile it
via "gcc -v" and you'll have the precise steps.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

From viridia at gmail.com  Mon Oct 19 03:49:48 2009
From: viridia at gmail.com (Talin)
Date: Mon, 19 Oct 2009 01:49:48 -0700
Subject: [LLVMdev] Still can't get source-level debugging to work
In-Reply-To: <b087fca00910190052p4c5d03eud73fad5b0de09f06@mail.gmail.com>
References: <d1b71f830910182349q7a447eb5yf64bfebca21374ae@mail.gmail.com> 
	<b087fca00910190017l67c08454j5848ab85e8824eff@mail.gmail.com> 
	<d1b71f830910190047h7e1e0e72u605a97bcd3098cdd@mail.gmail.com> 
	<b087fca00910190052p4c5d03eud73fad5b0de09f06@mail.gmail.com>
Message-ID: <d1b71f830910190149x3b337e4exb7045f247d1e8b96@mail.gmail.com>

OK I got it to work. Thank you so much :)

On Mon, Oct 19, 2009 at 12:52 AM, Anton Korobeynikov <
anton at korobeynikov.info> wrote:

> > Yes I am on darwin.
> I don't recall correctly, but there you cannot 'just' run gcc to get
> all dwarf stuff into the binary. You will also need to do some extra
> tool invocation (dsymutil?). Just pick some dummy c++ app, compile it
> via "gcc -v" and you'll have the precise steps.
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>



-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/6c9e9d00/attachment.html 

From ericbrunstad at mac.com  Mon Oct 19 07:32:36 2009
From: ericbrunstad at mac.com (Eric Brunstad)
Date: Mon, 19 Oct 2009 08:32:36 -0400
Subject: [LLVMdev] Objective-C code in lli
In-Reply-To: <C74EBDB4-4659-4561-809B-610CFCE72E15@apple.com>
References: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
	<C74EBDB4-4659-4561-809B-610CFCE72E15@apple.com>
Message-ID: <2D5F3FBE-F59C-4059-A1EE-F71453E84111@mac.com>

Hi,

What would be an estimate for the amount of work required to implement  
this?  Where would I get started if I were to implement it?

My goal is to run Objective-C programs in the interpreter so I can  
provide an application-sandbox by disallowing the invocation of  
certain C-functions and also by disallowing the invocation of certain  
Objective-C methods.

Thanks,

Eric

On Oct 19, 2009, at 12:01 AM, Chris Lattner wrote:

>
> On Oct 18, 2009, at 6:32 PM, Eric Brunstad wrote:
>
>> Hi,
>>
>> Is it possible to run Objective-C code in lli?  lli does not seem  
>> to want to load Foundation.framework.
>
> It is definitely possible, but we're not there yet.  LLI would have  
> to know about objective-c metadata to register it properly with the  
> runtime.  This is important for things like classes etc.  This isn't  
> conceptually hard, but noone has done it yet.
>
> -Chris
>
>>
>> Please see below.
>>
>> Thanks,
>>
>> Eric Brunstad
>>
>> #import <Foundation/Foundation.h>
>>
>> int main(int argc, char *argv[])
>> {
>> 	NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> 	NSLog(@"test!");
>> 	[pool drain];
>> 	return EXIT_SUCCESS;
>> }
>>
>> cmu-351714:llvm-2.5 ericbrunstad$ /Users/ericbrunstad/Downloads/ 
>> llvm-2.5/Release/bin/lli -force-interpreter=true -stats  /Users/ 
>> ericbrunstad/Desktop/test/test.o -load=/System/Library/Frameworks/ 
>> Foundation.framework/Foundation
>>
>> Could not resolve external global address:  
>> __CFConstantStringClassReference
>> 0   lli               0x0000000100687556 (anonymous  
>> namespace)::SignalHandler(int) + 470
>> 1   libSystem.B.dylib 0x00007fff83ee10aa _sigtramp + 26
>> 2   libSystem.B.dylib 0x0000000100a0b4ba _sigtramp + 2092082218
>> 3   lli               0x00000001001e8374  
>> llvm::ExecutionEngine::emitGlobals() + 6164
>> 4   lli               0x00000001001dbd69  
>> llvm::Interpreter::Interpreter(llvm::ModuleProvider*) + 185
>> 5   lli               0x00000001001dbdd8 llvm::Interpreter::create 
>> (llvm::ModuleProvider*, std::string*, bool) + 56
>> 6   lli               0x0000000100010803 main + 243
>> 7   lli               0x00000001000106e8 start + 52
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/4184b769/attachment.html 

From kennethuil at gmail.com  Mon Oct 19 08:03:33 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 19 Oct 2009 08:03:33 -0500
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<b087fca00910150829h2e660d7di6450b6e5db0ed0df@mail.gmail.com>
	<781F5EE8-E318-432A-8234-2B9D142859B6@apple.com>
	<6C9B9561-5EFC-4095-AC74-44B6DBB8FB98@illinois.edu>
	<35657f570910181951u9d8c9bcud85add877fb9670a@mail.gmail.com>
Message-ID: <400d33ea0910190603x357d6983m30efd02e6e529099@mail.gmail.com>

I've never heard of anyone forbidding their workers to distribute
videos of their non-secret-revealing talks.  Most tech companies want
to broadcast far and wide the talent of their people, and having them
give public talks and publicly distribute videos of same seems like a
good way to do that.

>> I hope you can pass my message along to the people at Apple who made
>> this decision.
>> ---
>>
>> I want to request Apple to make an exception and release the videos
>> and slides of presentations by Apple employees at the LLVM Developers'
>> Meeting. ?Several Apple employees now have a leadership role in the
>> LLVM community, although LLVM remains a widely used open source
>> software project. ?Their presentations at the LLVM developers' meeting
>> are an important component of how we help support LLVM users. ?The
>> presentations clearly reveal no confidential Apple information; in
>> fact, they were presented in front of a large number of external
>> participants. ?While we appreciate Apple's continued support of LLVM
>> and of the Developers' Meeting, the goodwill generated is being
>> undermined by this policy to withhold important technical information
>> from other LLVM users, and for little benefit to Apple.
>>
>> --Vikram Adve
>>
>> ----------------------------------------------------------------------
>> ?VIKRAM S. ADVE
>> ?Associate Professor, Computer Science ? ? ? E-MAIL: vadve at cs.uiuc.edu
>> ?Siebel Center for Computer Science ? ? ? ? ? PHONE: ? ?(217) 244-2016
>> ?Univ. of Illinois at Urbana-Champaign ? ? ? ? ?FAX: ? ?(217) 244-6500
>> ?201 N. Goodwin Ave.
>> ?Urbana IL 61801-2302. ? ? ? ? ? ? ? ? ? ? ? ? ?http://llvm.org/~vadve
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


From kennethuil at gmail.com  Mon Oct 19 08:05:08 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 19 Oct 2009 08:05:08 -0500
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
In-Reply-To: <14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
References: <4ADBD4E3.5090106@gmail.com>
	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
Message-ID: <400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>

On Sun, Oct 18, 2009 at 10:54 PM, Chris Lattner <clattner at apple.com> wrote:
>
> On Oct 18, 2009, at 7:54 PM, Talin wrote:
>
>> So I wasn't able to attend the developer meeting this year, even
>> though
>> I had signed up for it. This was a big disappointment to me,
>> particularly because I had hoped to get some hands-on assistance for
>> some unsolved problems that I have been struggling with for the last
>> six
>> months or so. Unfortunately, some of these problems aren't easily
>> reducible to a simple test case which I can send as an email
>> attachment,
>> and of the ones I do post on this list, about half go unanswered (not
>> that I'm casting blame, I know how these things go.) In any case, I
>> figured I would simply put those problems aside and then bring my
>> laptop
>> to the developer meeting and possibly get one or more of the LLVM
>> experts to spend some time with me. And then I had to go and miss the
>> meeting. :(
>>
>> So I kind of wonder if there are possibly other opportunities for
>> face-to-face interaction with the LLVM folks, on a smaller but more
>> frequent basis than the annual developer meeting. Something like a
>> user
>> group? :)
>
> Sure, sounds fun. ?We just lack an organizer. ?If you make it happen,
> I'm pretty sure people will come :)
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

That would all depend on how many LLVM users there are within easy
driving distance of you.  I guess a good way to find out is to post
your physical location here and see how many nibbles you get.


From devlists at shadowlab.org  Mon Oct 19 08:24:20 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Mon, 19 Oct 2009 15:24:20 +0200
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
In-Reply-To: <400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>
References: <4ADBD4E3.5090106@gmail.com>
	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
	<400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>
Message-ID: <D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>


Le 19 oct. 2009 ? 15:05, Kenneth Uildriks a ?crit :

> On Sun, Oct 18, 2009 at 10:54 PM, Chris Lattner <clattner at apple.com>  
> wrote:
>>
>> On Oct 18, 2009, at 7:54 PM, Talin wrote:
>>
>>> So I wasn't able to attend the developer meeting this year, even
>>> though
>>> I had signed up for it. This was a big disappointment to me,
>>> particularly because I had hoped to get some hands-on assistance for
>>> some unsolved problems that I have been struggling with for the last
>>> six
>>> months or so. Unfortunately, some of these problems aren't easily
>>> reducible to a simple test case which I can send as an email
>>> attachment,
>>> and of the ones I do post on this list, about half go unanswered  
>>> (not
>>> that I'm casting blame, I know how these things go.) In any case, I
>>> figured I would simply put those problems aside and then bring my
>>> laptop
>>> to the developer meeting and possibly get one or more of the LLVM
>>> experts to spend some time with me. And then I had to go and miss  
>>> the
>>> meeting. :(
>>>
>>> So I kind of wonder if there are possibly other opportunities for
>>> face-to-face interaction with the LLVM folks, on a smaller but more
>>> frequent basis than the annual developer meeting. Something like a
>>> user
>>> group? :)
>>
>> Sure, sounds fun.  We just lack an organizer.  If you make it happen,
>> I'm pretty sure people will come :)
>>
>> -Chris
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> That would all depend on how many LLVM users there are within easy
> driving distance of you.  I guess a good way to find out is to post
> your physical location here and see how many nibbles you get.

FWIW, there is a LLVM bar camp planed in Paris the next month:

http://barcamp.org/LLVM%20BarCamp%20Paris (French web page)


-- Jean-Daniel






From espindola at google.com  Mon Oct 19 09:53:25 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 19 Oct 2009 10:53:25 -0400
Subject: [LLVMdev] Mirroring of LLVM repository
In-Reply-To: <1249413534-sup-9663@strider>
References: <b087fca00908031209x234c949r369f0868fcbca849@mail.gmail.com>
	<1249344900-sup-9515@strider>
	<38a0d8450908041156t279264c1p70ce3afd3bb245d5@mail.gmail.com>
	<1249413534-sup-9663@strider>
Message-ID: <38a0d8450910190753q5f90b971k455fd3607c4d75a4@mail.gmail.com>

> Yes, my bad, the instructions were a bit too specific to my Github
> mirror. The following scheme bootstraps git-svn and works with all
> mirrors, including those on repo.or.cz:
>
> ? ?mkdir llvm-gcc-4.2
> ? ?cd llvm-gcc-4.2
> ? ?git init
> ? ?git pull git://repo.or.cz/llvm-gcc-4.2.git master:remotes/git-svn
> ? ?git svn init https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk
> ? ?git svn rebase --local

This works nicely, but I can only use "git svn rebase" for updating.
Is that I way I could use both "git pull" and "git svn rebase"? I
tried to adapt http://gcc.gnu.org/wiki/GitMirror, but I am lost. What
I tried was adding

[remote "origin"]
        url = git://repo.or.cz/clang.git
        fetch = master:remotes/git-svn

to the config file. It works until I do the first "git svn rebase".
After that I get

>From git://repo.or.cz/clang
 ! [rejected]        master     -> git-svn  (non fast forward)


> --
> Regards,
> Andreas

Cheers,
-- 
Rafael ?vila de Esp?ndola


From Ken.Dyck at onsemi.com  Mon Oct 19 09:55:27 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Mon, 19 Oct 2009 07:55:27 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <200910161545.57727.dag@cray.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com><200910161236.35627.dag@cray.com>
	<4AD8D93E.1020206@gmx.de> <200910161545.57727.dag@cray.com>
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>

I'd also like to register my disappointment that the slides and videos
aren't available. 

On Friday, October 16, 2009 4:46 PM, David Greene wrote:
> When I agreed to be a speaker, I signed off on having my 
> talk made publicly available.  There does seem to be a 
> double-standard here and that's concerning.

There are few things about this whole situation that aren't clear to me:

1. With what organization were these speaker agreements made?
2. Did the speakers from Apple sign the same agreements?
3. If the agreements were made with an organization other than Apple, on
what basis are the materials being witheld? 
3a. That is, do the Dev Meeting organizers, or whichever organization it
was that issued the agreements, already have legal permission to release
them?
3b. What would be the consequences of releasing the materials without
Apple's approval?
4. If the agreements were made with Apple, why?
4a. Is there a need for the community to establish an independent legal
entity (similar to the FSF or the Apache Software Foundation) to govern
LLVM development and organize developer meetings?

-Ken










From baldrick at free.fr  Mon Oct 19 10:38:39 2009
From: baldrick at free.fr (Duncan Sands)
Date: Mon, 19 Oct 2009 17:38:39 +0200
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com><200910161236.35627.dag@cray.com>	<4AD8D93E.1020206@gmx.de>
	<200910161545.57727.dag@cray.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
Message-ID: <4ADC87FF.6070007@free.fr>

Ken Dyck wrote:
> I'd also like to register my disappointment that the slides and videos
> aren't available.

I would have liked to have seen Nate Begeman's talk on OpenCL.  It seems
odd to me that Nate is able to distribute his code openly, via public
commits to the LLVM subversion repository, but isn't allowed to explain
his work in public.

Ciao,

Duncan.

From juanc.martinez.santos at gmail.com  Mon Oct 19 10:40:17 2009
From: juanc.martinez.santos at gmail.com (Juan Carlos Martinez Santos)
Date: Mon, 19 Oct 2009 11:40:17 -0400
Subject: [LLVMdev] Using address space attribute in LLVM
Message-ID: <d17b77a40910190840p1d5e4d16g92f33f8316409b9@mail.gmail.com>

Hello,

What is the correct way to use address_space attribute? For CLANG, I used
the below code, but when I tried the same with LLVM, I got a warning.

Thanks in advance,

Juan Carlos

-----------------------------

Code used:

#define GS_RELATIVE __attribute__((address_space(256)))
int foo(int GS_RELATIVE *P) {
  return *P;
}
 int main(){
        return (1);
}
------------------------------

LLVM messsage:

~/test$ llvm-gcc addrspace256.c -emit-llvm -o -
addrspace256.c:2: warning: 'address_space' attribute directive ignored
/tmp/ccpdq1E2.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status


-- 
Juan Carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/bec9082e/attachment.html 

From kennethuil at gmail.com  Mon Oct 19 10:40:17 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Mon, 19 Oct 2009 10:40:17 -0500
Subject: [LLVMdev] Who is physically near Austin?
Message-ID: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>

I'm taking Talin's idea and running with it with respect to the Austin
area.  If you're into LLVM and within easy-enough driving distance to
make it worthwhile to get together every month or so in Austin, please
post here.  If there's enough interest, I'll set something up at a
local restaurant or someplace like that.

From clattner at apple.com  Mon Oct 19 10:53:54 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Oct 2009 08:53:54 -0700
Subject: [LLVMdev] Using address space attribute in LLVM
In-Reply-To: <d17b77a40910190840p1d5e4d16g92f33f8316409b9@mail.gmail.com>
References: <d17b77a40910190840p1d5e4d16g92f33f8316409b9@mail.gmail.com>
Message-ID: <8BF3A409-9C39-48B6-A3BC-5A6A5BB29FCC@apple.com>


On Oct 19, 2009, at 8:40 AM, Juan Carlos Martinez Santos wrote:

> Hello,
>
> What is the correct way to use address_space attribute? For CLANG, I  
> used the below code, but when I tried the same with LLVM, I got a  
> warning.

llvm-gcc doesn't support address spaces.  This is a clang-only feature.

-Chris

>
> Thanks in advance,
>
> Juan Carlos
>
> -----------------------------
>
> Code used:
>
> #define GS_RELATIVE __attribute__((address_space(256)))
> int foo(int GS_RELATIVE *P) {
>   return *P;
> }
>  int main(){
>         return (1);
> }
> ------------------------------
>
> LLVM messsage:
>
> ~/test$ llvm-gcc addrspace256.c -emit-llvm -o -
> addrspace256.c:2: warning: 'address_space' attribute directive ignored
> /tmp/ccpdq1E2.o: file not recognized: File format not recognized
> collect2: ld returned 1 exit status
>
>
> -- 
> Juan Carlos
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From clattner at apple.com  Mon Oct 19 10:54:54 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Oct 2009 08:54:54 -0700
Subject: [LLVMdev] Objective-C code in lli
In-Reply-To: <2D5F3FBE-F59C-4059-A1EE-F71453E84111@mac.com>
References: <892CC668-FFF5-4D1F-B880-550E0762A668@mac.com>
	<C74EBDB4-4659-4561-809B-610CFCE72E15@apple.com>
	<2D5F3FBE-F59C-4059-A1EE-F71453E84111@mac.com>
Message-ID: <3B4F445D-8F66-4B55-BEBE-83B4C7C61970@apple.com>


On Oct 19, 2009, at 5:32 AM, Eric Brunstad wrote:

> Hi,
>
> What would be an estimate for the amount of work required to  
> implement this?  Where would I get started if I were to implement it?
>
> My goal is to run Objective-C programs in the interpreter so I can  
> provide an application-sandbox by disallowing the invocation of  
> certain C-functions and also by disallowing the invocation of  
> certain Objective-C methods.

I don't really know.  I'd start by reading up on the ObjC runtime  
interfaces and grabbing a copy of it from the open darwin site.  See  
what it does at startup time to register metadata and do the  
equivalent of that.

Alternatively, you can try running apps and debug specific failures.

-Chris

>
> Thanks,
>
> Eric
>
> On Oct 19, 2009, at 12:01 AM, Chris Lattner wrote:
>
>>
>> On Oct 18, 2009, at 6:32 PM, Eric Brunstad wrote:
>>
>>> Hi,
>>>
>>> Is it possible to run Objective-C code in lli?  lli does not seem  
>>> to want to load Foundation.framework.
>>
>> It is definitely possible, but we're not there yet.  LLI would have  
>> to know about objective-c metadata to register it properly with the  
>> runtime.  This is important for things like classes etc.  This  
>> isn't conceptually hard, but noone has done it yet.
>>
>> -Chris
>>
>>>
>>> Please see below.
>>>
>>> Thanks,
>>>
>>> Eric Brunstad
>>>
>>> #import <Foundation/Foundation.h>
>>>
>>> int main(int argc, char *argv[])
>>> {
>>> 	NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>> 	NSLog(@"test!");
>>> 	[pool drain];
>>> 	return EXIT_SUCCESS;
>>> }
>>>
>>> cmu-351714:llvm-2.5 ericbrunstad$ /Users/ericbrunstad/Downloads/ 
>>> llvm-2.5/Release/bin/lli -force-interpreter=true -stats  /Users/ 
>>> ericbrunstad/Desktop/test/test.o -load=/System/Library/Frameworks/ 
>>> Foundation.framework/Foundation
>>>
>>> Could not resolve external global address:  
>>> __CFConstantStringClassReference
>>> 0   lli               0x0000000100687556 (anonymous  
>>> namespace)::SignalHandler(int) + 470
>>> 1   libSystem.B.dylib 0x00007fff83ee10aa _sigtramp + 26
>>> 2   libSystem.B.dylib 0x0000000100a0b4ba _sigtramp + 2092082218
>>> 3   lli               0x00000001001e8374  
>>> llvm::ExecutionEngine::emitGlobals() + 6164
>>> 4   lli               0x00000001001dbd69  
>>> llvm::Interpreter::Interpreter(llvm::ModuleProvider*) + 185
>>> 5   lli               0x00000001001dbdd8 llvm::Interpreter::create 
>>> (llvm::ModuleProvider*, std::string*, bool) + 56
>>> 6   lli               0x0000000100010803 main + 243
>>> 7   lli               0x00000001000106e8 start + 52
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/c5816ec7/attachment.html 

From adasgupt at qualcomm.com  Mon Oct 19 11:55:23 2009
From: adasgupt at qualcomm.com (Das Gupta, Anshu)
Date: Mon, 19 Oct 2009 09:55:23 -0700
Subject: [LLVMdev] Who is physically near Austin?
In-Reply-To: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>
References: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>
Message-ID: <95F3F8528575B744B641026CAA4A9EDC1EDB297916@NASANEXMB06.na.qualcomm.com>

Kenneth,

I am interested in a monthly LLVM meeting in Austin. At least one more member of my team at Qualcomm, Austin will be interested as well.

-Anshu


-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kenneth Uildriks
Sent: Monday, October 19, 2009 10:40 AM
To: LLVM Developers Mailing List
Subject: [LLVMdev] Who is physically near Austin?

I'm taking Talin's idea and running with it with respect to the Austin
area.  If you're into LLVM and within easy-enough driving distance to
make it worthwhile to get together every month or so in Austin, please
post here.  If there's enough interest, I'll set something up at a
local restaurant or someplace like that.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From clattner at apple.com  Mon Oct 19 12:02:45 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Oct 2009 10:02:45 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<200910161236.35627.dag@cray.com> <4AD8D93E.1020206@gmx.de>
	<200910161545.57727.dag@cray.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
Message-ID: <68DCAEC7-C869-4C11-B70C-3B3A4DD75239@apple.com>

On Oct 19, 2009, at 7:55 AM, Ken Dyck wrote:

> I'd also like to register my disappointment that the slides and videos
> aren't available.
>
> On Friday, October 16, 2009 4:46 PM, David Greene wrote:
>> When I agreed to be a speaker, I signed off on having my
>> talk made publicly available.  There does seem to be a
>> double-standard here and that's concerning.
>
> There are few things about this whole situation that aren't clear to  
> me:
>
> 1. With what organization were these speaker agreements made?

With the developer meeting organizers.

> 2. Did the speakers from Apple sign the same agreements?

No, it turns out that they generally didn't because we didn't  
anticipate a problem.  Even if they did, the speakers themselves don't  
have authority to release this, they generally have to check with  
their employers.

> 3. If the agreements were made with an organization other than  
> Apple, on
> what basis are the materials being witheld?
> 3a. That is, do the Dev Meeting organizers, or whichever  
> organization it
> was that issued the agreements, already have legal permission to  
> release
> them?
> 3b. What would be the consequences of releasing the materials without
> Apple's approval?

As I stated previously, we found out about this extremely late into  
the process.  There is a high probability that at least some of the  
slides will get released in time.

> 4. If the agreements were made with Apple, why?

n/a.

> 4a. Is there a need for the community to establish an independent  
> legal
> entity (similar to the FSF or the Apache Software Foundation) to  
> govern
> LLVM development and organize developer meetings?

I agree that a third party foundation would be useful for other  
reasons, but this wouldn't help anything in this case.

My read of your position here is that you're coming at this from a  
confused angle.  From my perspective, Apple has some just about  
everything right w.r.t. developing LLVM in the open, contributing  
code, fostering development etc.  The only major problem to date has  
been around speakers at the developer meeting, which is a pretty minor  
issue in the big picture, and still is an ongoing debate (so it isn't  
a done deal).

Getting back to "it wouldn't help anything": if the Developer Meeting  
were held elsewhere and if the current rule was still in place, it  
would be very simple: there would be no Apple speakers because they  
wouldn't be able to sign the form.  This doesn't seem to achieve your  
goal of making those talks public.

-Chris


From andrewl at lenharth.org  Mon Oct 19 12:04:32 2009
From: andrewl at lenharth.org (Andrew Lenharth)
Date: Mon, 19 Oct 2009 12:04:32 -0500
Subject: [LLVMdev] Who is physically near Austin?
In-Reply-To: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>
References: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>
Message-ID: <85dfcd7f0910191004y748a5b40le98641e49f15e7a5@mail.gmail.com>

On Mon, Oct 19, 2009 at 10:40 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> I'm taking Talin's idea and running with it with respect to the Austin
> area. ?If you're into LLVM and within easy-enough driving distance to
> make it worthwhile to get together every month or so in Austin, please
> post here. ?If there's enough interest, I'll set something up at a
> local restaurant or someplace like that.

I would be interested in this, but I'm not moving to Austin until this summer.

Andrew


From chrisstocktonaz at gmail.com  Mon Oct 19 12:45:46 2009
From: chrisstocktonaz at gmail.com (Chris Stockton)
Date: Mon, 19 Oct 2009 10:45:46 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <68DCAEC7-C869-4C11-B70C-3B3A4DD75239@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<200910161236.35627.dag@cray.com> <4AD8D93E.1020206@gmx.de>
	<200910161545.57727.dag@cray.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
	<68DCAEC7-C869-4C11-B70C-3B3A4DD75239@apple.com>
Message-ID: <e2e02fe0910191045w60368963t683481681883cd08@mail.gmail.com>

+1 for releasing both videos and slides, "ScalarEvolution and Loop
Optimization" is my primary interest but surely would get around to the
others as well.

On Oct 19, 2009 10:05 AM, "Chris Lattner" <clattner at apple.com> wrote:

On Oct 19, 2009, at 7:55 AM, Ken Dyck wrote: > I'd also like to register my
disappointment that the...
With the developer meeting organizers.

> 2. Did the speakers from Apple sign the same agreements?
No, it turns out that they generally didn't because we didn't
anticipate a problem.  Even if they did, the speakers themselves don't
have authority to release this, they generally have to check with
their employers.

> 3. If the agreements were made with an organization other than > Apple, on
> what basis are the...
As I stated previously, we found out about this extremely late into
the process.  There is a high probability that at least some of the
slides will get released in time.

> 4. If the agreements were made with Apple, why?
n/a.

> 4a. Is there a need for the community to establish an independent > legal
> entity (similar to ...
I agree that a third party foundation would be useful for other
reasons, but this wouldn't help anything in this case.

My read of your position here is that you're coming at this from a
confused angle.  From my perspective, Apple has some just about
everything right w.r.t. developing LLVM in the open, contributing
code, fostering development etc.  The only major problem to date has
been around speakers at the developer meeting, which is a pretty minor
issue in the big picture, and still is an ongoing debate (so it isn't
a done deal).

Getting back to "it wouldn't help anything": if the Developer Meeting
were held elsewhere and if the current rule was still in place, it
would be very simple: there would be no Apple speakers because they
wouldn't be able to sign the form.  This doesn't seem to achieve your
goal of making those talks public.

-Chris

_______________________________________________ LLVM Developers mailing list
LLVMdev at cs.uiuc.edu ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/9815821d/attachment.html 

From espindola at google.com  Mon Oct 19 12:57:08 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 19 Oct 2009 13:57:08 -0400
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <4ADA7F0D.4050107@mxc.ca>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC> <4ADA7F0D.4050107@mxc.ca>
Message-ID: <38a0d8450910191057g1a7610b9p891f428d0b30766e@mail.gmail.com>

> Binutils 2.20 supports plugins and 'ar' and 'nm' will work with the gold
> plugin. Not sure about ranlib.

ranlib is ar :-)

> Nick

Cheers,
-- 
Rafael ?vila de Esp?ndola


From Ken.Dyck at onsemi.com  Mon Oct 19 12:53:31 2009
From: Ken.Dyck at onsemi.com (Ken Dyck)
Date: Mon, 19 Oct 2009 10:53:31 -0700
Subject: [LLVMdev] [cfe-dev] Developer meeting videos up
In-Reply-To: <68DCAEC7-C869-4C11-B70C-3B3A4DD75239@apple.com>
References: <0B217D2A-B7CA-49D8-83DB-6C39B9BAED87@apple.com>
	<200910161236.35627.dag@cray.com> <4AD8D93E.1020206@gmx.de>
	<200910161545.57727.dag@cray.com>
	<8F2E4A8BCDA0B84DA6C9088EB5B277478443FE@NAMAIL.ad.onsemi.com>
	<68DCAEC7-C869-4C11-B70C-3B3A4DD75239@apple.com>
Message-ID: <8F2E4A8BCDA0B84DA6C9088EB5B27747844545@NAMAIL.ad.onsemi.com>

On Monday, October 19, 2009 1:03 PM, Chris Lattner wrote:
> My read of your position here is that you're coming at this 
> from a confused angle.  

So it seems. Thanks for clarifying.

-Ken


From espindola at google.com  Mon Oct 19 12:58:37 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 19 Oct 2009 13:58:37 -0400
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <1255833619.23327.15.camel@UIUC>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC> <4ADA7F0D.4050107@mxc.ca>
	<1255833619.23327.15.camel@UIUC>
Message-ID: <38a0d8450910191058k552b003fo1d25654430df463c@mail.gmail.com>

2009/10/17 zhunan <zhunansjtu at gmail.com>:
> Thank you for the reply,but I meant that when we building,we can not use
> the native tools such ar and as to process the llvm files,we must have
> the ability to call llvm-ar and llvm-as instead of the native ones.

We can use the native tools if they understand llvm IL :-)

That is what the plugin does. With it installed you can run nm in a
file with LLVM IL and it will print you the symbols. You can also add
IL files to an archive and the archive will have a correct symbol
table.

Cheers,
-- 
Rafael ?vila de Esp?ndola


From brooks at freebsd.org  Mon Oct 19 14:42:59 2009
From: brooks at freebsd.org (Brooks Davis)
Date: Mon, 19 Oct 2009 14:42:59 -0500
Subject: [LLVMdev] compiler-rt install target
Message-ID: <20091019194259.GA91296@lor.one-eyed-alien.net>

I've added a compiler-rt port to the FreeBSD ports collection and one
thing I noticed is that the install target installs the blocks runtime,
but doesn't install libCompilerRT-Common.a or any non-blocks header
files.  Is this intentional?

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/e5df82d8/attachment.bin 

From echristo at apple.com  Mon Oct 19 16:03:31 2009
From: echristo at apple.com (Eric Christopher)
Date: Mon, 19 Oct 2009 14:03:31 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
Message-ID: <BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>


On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote:

> If you haven't already tried it, please consider switch to 'make
> check-lit' as an alternative to 'make check'. If it doesn't work for
> you, or you find it doesn't do something DejaGNU did and you like,
> please let me know. My eventual plan is to move to lit entirely and
> drop DejaGNU support, so consider yourself warned.

I've swapped all of my testing to lit since all I do is native and  
it's been great.  I'm definitely in favor of Chris's suggestion that  
we move to that as the default.

One quick feature question: one of the nifty things about dejagnu  
(really the only nifty thing) is that it supported remote execution of  
binaries - I don't use that right now, but other people may. Any idea  
if you plan on having lit support that? Honestly I doubt it would be  
hard in python. Probably a "if someone has a need" feature? :)

-eric

From shreyas76 at gmail.com  Mon Oct 19 16:23:23 2009
From: shreyas76 at gmail.com (shreyas krishnan)
Date: Mon, 19 Oct 2009 14:23:23 -0700
Subject: [LLVMdev] generic instruction
Message-ID: <24389fb30910191423p5e24e408o8231e9ef6f8f1910@mail.gmail.com>

Hi
   I  need a pseudo instruction that can carry a variable number -
still a small  number b/w 2-6 - of immediate values. I have two
different uses for such an instruction

1. I one scenario,  they translate to immediate moves after register allocation
2. In a different one, they carry information about other
non-immediate operands.

Short of declaring different formats in the td for each case, is there
a generic way to carry such information, say an index perhaps ?

thanks for any pointers
shrey

From daniel at zuster.org  Mon Oct 19 16:24:24 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 19 Oct 2009 14:24:24 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
Message-ID: <6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>

On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote:
> On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote:
>> If you haven't already tried it, please consider switch to 'make
>> check-lit' as an alternative to 'make check'. If it doesn't work for
>> you, or you find it doesn't do something DejaGNU did and you like,
>> please let me know. My eventual plan is to move to lit entirely and
>> drop DejaGNU support, so consider yourself warned.
>
> I've swapped all of my testing to lit since all I do is native and it's been
> great. ?I'm definitely in favor of Chris's suggestion that we move to that
> as the default.

Yay!

> One quick feature question: one of the nifty things about dejagnu (really
> the only nifty thing) is that it supported remote execution of binaries - I
> don't use that right now, but other people may. Any idea if you plan on
> having lit support that? Honestly I doubt it would be hard in python.
> Probably a "if someone has a need" feature? :)

Should be possible, although I don't know anything about the dejagnu
feature. However, 'lit' has a reasonably complete shell and Tcl parser
so it knows what commands are being called, so at least in theory it
should be able to rewrite them.

 - Daniel


From eocallaghan at auroraux.org  Mon Oct 19 17:23:16 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Mon, 19 Oct 2009 23:23:16 +0100
Subject: [LLVMdev] compiler-rt install target
In-Reply-To: <20091019194259.GA91296@lor.one-eyed-alien.net>
References: <20091019194259.GA91296@lor.one-eyed-alien.net>
Message-ID: <521640720910191523p529f813fv4c6ac66ba4c89e74@mail.gmail.com>

G'Day,

If you mean the cmake build system then no, its just not competed yet,
patches really really welcome!
I just had such really really limited time to work on so much (many
projects) on my own.

Thanks for your time and testing,
Cheers,
Edward O'Callaghan.

2009/10/19 Brooks Davis <brooks at freebsd.org>:
> I've added a compiler-rt port to the FreeBSD ports collection and one
> thing I noticed is that the install target installs the blocks runtime,
> but doesn't install libCompilerRT-Common.a or any non-blocks header
> files. ?Is this intentional?
>
> -- Brooks
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From echristo at apple.com  Mon Oct 19 17:58:36 2009
From: echristo at apple.com (Eric Christopher)
Date: Mon, 19 Oct 2009 15:58:36 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
	<6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
Message-ID: <7CFFBB67-206C-4CD7-9B15-318065FD9240@apple.com>

>
> Should be possible, although I don't know anything about the dejagnu
> feature. However, 'lit' has a reasonably complete shell and Tcl parser
> so it knows what commands are being called, so at least in theory it
> should be able to rewrite them.

Interesting. Even less of that would be just duplicating the  
functionality. At any rate everything looks quite nice.

Thanks!

-eric

From deeppatel1987 at gmail.com  Mon Oct 19 18:06:23 2009
From: deeppatel1987 at gmail.com (Sandeep Patel)
Date: Mon, 19 Oct 2009 23:06:23 +0000
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
	<6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
Message-ID: <305d6f60910191606y3881ced4j6594ab4541f3bdfc@mail.gmail.com>

On Mon, Oct 19, 2009 at 9:24 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> On Mon, Oct 19, 2009 at 2:03 PM, Eric Christopher <echristo at apple.com> wrote:
>> On Oct 18, 2009, at 7:49 PM, Daniel Dunbar wrote:
>>> If you haven't already tried it, please consider switch to 'make
>>> check-lit' as an alternative to 'make check'. If it doesn't work for
>>> you, or you find it doesn't do something DejaGNU did and you like,
>>> please let me know. My eventual plan is to move to lit entirely and
>>> drop DejaGNU support, so consider yourself warned.
>>
>> I've swapped all of my testing to lit since all I do is native and it's been
>> great. ?I'm definitely in favor of Chris's suggestion that we move to that
>> as the default.
>
> Yay!
>
>> One quick feature question: one of the nifty things about dejagnu (really
>> the only nifty thing) is that it supported remote execution of binaries - I
>> don't use that right now, but other people may. Any idea if you plan on
>> having lit support that? Honestly I doubt it would be hard in python.
>> Probably a "if someone has a need" feature? :)
>
> Should be possible, although I don't know anything about the dejagnu
> feature. However, 'lit' has a reasonably complete shell and Tcl parser
> so it knows what commands are being called, so at least in theory it
> should be able to rewrite them.

FWIW, this is a feature we're currently using and caused me to make
numerous changes to the makefiles a while back. If this is entirely
going away, then bringing up a buildbot with a Beagleboard attached is
going to be a much bigger task than I hoped.

deep


From grosbach at apple.com  Mon Oct 19 18:32:16 2009
From: grosbach at apple.com (Jim Grosbach)
Date: Mon, 19 Oct 2009 16:32:16 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <7CFFBB67-206C-4CD7-9B15-318065FD9240@apple.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
	<6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
	<7CFFBB67-206C-4CD7-9B15-318065FD9240@apple.com>
Message-ID: <C33BBB21-1E0A-41C7-9EF1-AD830A421AD2@apple.com>


On Oct 19, 2009, at 3:58 PM, Eric Christopher wrote:

>>
>> Should be possible, although I don't know anything about the dejagnu
>> feature. However, 'lit' has a reasonably complete shell and Tcl  
>> parser
>> so it knows what commands are being called, so at least in theory it
>> should be able to rewrite them.
>
> Interesting. Even less of that would be just duplicating the
> functionality. At any rate everything looks quite nice.
>

Why not abstracting the "copy to target," "run on target," "get  
results from target," etc. commands? For the default (hosted) case,  
they're pretty much trivial. For remote targets, they can be defined  
in terms of RSH, SSH, or whatever. As I recall, dejagnu does something  
along those lines.


> Thanks!
>
> -eric
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From echristo at apple.com  Mon Oct 19 18:34:33 2009
From: echristo at apple.com (Eric Christopher)
Date: Mon, 19 Oct 2009 16:34:33 -0700
Subject: [LLVMdev] RFC: Dropping DejaGNU
In-Reply-To: <C33BBB21-1E0A-41C7-9EF1-AD830A421AD2@apple.com>
References: <6a8523d60910181949h4ec6c24aja00ae8294c59e721@mail.gmail.com>
	<BCE4F57C-7E3E-4E72-9694-348665374A1F@apple.com>
	<6a8523d60910191424q744256ebo66d0f792d6db2bd5@mail.gmail.com>
	<7CFFBB67-206C-4CD7-9B15-318065FD9240@apple.com>
	<C33BBB21-1E0A-41C7-9EF1-AD830A421AD2@apple.com>
Message-ID: <3A16901B-DCE7-4030-94A4-005FEB02DF7E@apple.com>


On Oct 19, 2009, at 4:32 PM, Jim Grosbach wrote:

>
> On Oct 19, 2009, at 3:58 PM, Eric Christopher wrote:
>
>>>
>>> Should be possible, although I don't know anything about the dejagnu
>>> feature. However, 'lit' has a reasonably complete shell and Tcl  
>>> parser
>>> so it knows what commands are being called, so at least in theory it
>>> should be able to rewrite them.
>>
>> Interesting. Even less of that would be just duplicating the
>> functionality. At any rate everything looks quite nice.
>>
>
> Why not abstracting the "copy to target," "run on target," "get  
> results from target," etc. commands? For the default (hosted) case,  
> they're pretty much trivial. For remote targets, they can be defined  
> in terms of RSH, SSH, or whatever. As I recall, dejagnu does  
> something along those lines.

Pretty much what I was thinking, yes.

Anyhow, not a major issue on my end at the moment :)

-eric

From horwitz at cs.wisc.edu  Mon Oct 19 19:20:06 2009
From: horwitz at cs.wisc.edu (Susan Horwitz)
Date: Mon, 19 Oct 2009 19:20:06 -0500 (CDT)
Subject: [LLVMdev] request for help writing a register allocator
Message-ID: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>

I'm using LLVM for a compiler course, and I'd like to have my students 
implement a graph-coloring register allocator.  I'm having a lot of 
trouble figuring out how this should be done.

Is there anyone who has written an LLVM register allocator who would be 
willing to help me understand the basic ideas?  I understand the 
algorithm, it's LLVM that I don't understand.  For example:

- When allocating registers, how do I know which register class to use,
   and which registers of that class are available?

- How do I know which operands of a Machine Instruction are candidates
   for (simple) register allocation (e.g., are of type int)?

- How do I replace a virtual register with a physical one?

- Do I need to generate spill code to handle virtual registers that
   cannot be replaced with physical ones, and if so, how?


Susan Horwitz


From zhunansjtu at gmail.com  Mon Oct 19 19:40:26 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Tue, 20 Oct 2009 08:40:26 +0800
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <38a0d8450910191058k552b003fo1d25654430df463c@mail.gmail.com>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC> <4ADA7F0D.4050107@mxc.ca>
	<1255833619.23327.15.camel@UIUC>
	<38a0d8450910191058k552b003fo1d25654430df463c@mail.gmail.com>
Message-ID: <1255999226.6513.8.camel@UIUC>

Yes,but when I just simply replace lto_codegen_compile(cg, ...) with
lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the
gold-plugin.cpp to see if it will generate a correct bc file,the
llvm-gcc/llvm-g++ will call the native ld in the linking step,which
causes the failture because of that ld can not recognize an object file
which contains LLVM's IL.

I understand the failture as this: libLLVMgold.so is just a plugin for
ld but not llvm-ld,when I want to build a whole-program bitcodes,llvm-ld
is the only available tool,so I think gold-plugin is not very useful to
archieve the goal,I'm considering to modify the codes of llvm-gcc's
collect2 to make it call llvm-ld automatically when receive certain
options.

Thanks 




? 2009-10-19?? 13:58 -0400?Rafael Espindola???
> 2009/10/17 zhunan <zhunansjtu at gmail.com>:
> > Thank you for the reply,but I meant that when we building,we can not use
> > the native tools such ar and as to process the llvm files,we must have
> > the ability to call llvm-ar and llvm-as instead of the native ones.
> 
> We can use the native tools if they understand llvm IL :-)
> 
> That is what the plugin does. With it installed you can run nm in a
> file with LLVM IL and it will print you the symbols. You can also add
> IL files to an archive and the archive will have a correct symbol
> table.
> 
> Cheers,


From grosbach at apple.com  Mon Oct 19 20:01:27 2009
From: grosbach at apple.com (Jim Grosbach)
Date: Mon, 19 Oct 2009 18:01:27 -0700
Subject: [LLVMdev] request for help writing a register allocator
In-Reply-To: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
References: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
Message-ID: <E2113887-CA1A-41E8-848C-794E629196BB@apple.com>

Hi Susan,

You may find the PBQP allocator implementation useful as a reference  
to what's involved in adding a new allocator to LLVM. It's located in  
lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/CodeGen/ 
PBQP directory.

I'm no expert on the LLVM register allocation interfaces, so I'll  
defer to those who are regarding the specifics of your questions.

-Jim

On Oct 19, 2009, at 5:20 PM, Susan Horwitz wrote:

> I'm using LLVM for a compiler course, and I'd like to have my students
> implement a graph-coloring register allocator.  I'm having a lot of
> trouble figuring out how this should be done.
>
> Is there anyone who has written an LLVM register allocator who would  
> be
> willing to help me understand the basic ideas?  I understand the
> algorithm, it's LLVM that I don't understand.  For example:
>
> - When allocating registers, how do I know which register class to  
> use,
>   and which registers of that class are available?
>
> - How do I know which operands of a Machine Instruction are candidates
>   for (simple) register allocation (e.g., are of type int)?
>
> - How do I replace a virtual register with a physical one?
>
> - Do I need to generate spill code to handle virtual registers that
>   cannot be replaced with physical ones, and if so, how?
>
>
> Susan Horwitz
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From regehr at cs.utah.edu  Mon Oct 19 21:03:51 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 19 Oct 2009 20:03:51 -0600
Subject: [LLVMdev] self-hosting failure
Message-ID: <4ADD1A87.1010106@cs.utah.edu>

I've been getting the error for a release build for the last 24 hours or 
so.   This is on Ubuntu Jaunty on x86.  Known problem?  If not, does 
anyone have an easy recipe for getting the build system to tell me the 
command line that's being used and to leave a preprocessed file sitting 
around?

Thanks,

John


llvm[2]: Compiling UnreachableBlockElim.cpp for Release build
StrongPHIElimination.cpp: In member function '(anonymous 
namespace)::StrongPHIElimination::InsertCopies(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*, 
llvm::SmallPtrSet<llvm::MachineBasicBlock*, 16u>&)':
StrongPHIElimination.cpp:1051:1: internal compiler error: in 
rewrite_stmt, at tree-into-ssa.c:1302
Please submit a full bug report,


From mrs at apple.com  Mon Oct 19 21:26:30 2009
From: mrs at apple.com (Mike Stump)
Date: Mon, 19 Oct 2009 19:26:30 -0700
Subject: [LLVMdev] self-hosting failure
In-Reply-To: <4ADD1A87.1010106@cs.utah.edu>
References: <4ADD1A87.1010106@cs.utah.edu>
Message-ID: <596D1729-7B3F-4B2D-8958-0E6B5CAE09FD@apple.com>

On Oct 19, 2009, at 7:03 PM, John Regehr wrote:
> I've been getting the error for a release build for the last 24  
> hours or
> so.   This is on Ubuntu Jaunty on x86.  Known problem?  If not, does
> anyone have an easy recipe for getting the build system to tell me the
> command line that's being used and to leave a preprocessed file  
> sitting
> around?

   make VERBOSE=1

will show you the compile line in use.  If you add -save-temps to the  
build, it should save the .ii file from that translation unit.  Hope  
this helps.  I normally just cut and paste the command and add the - 
save-temps by hand.  Adding -v to a gcc command is at times is helpful  
too.

From daniel at zuster.org  Mon Oct 19 21:27:30 2009
From: daniel at zuster.org (Daniel Dunbar)
Date: Mon, 19 Oct 2009 19:27:30 -0700
Subject: [LLVMdev] self-hosting failure
In-Reply-To: <4ADD1A87.1010106@cs.utah.edu>
References: <4ADD1A87.1010106@cs.utah.edu>
Message-ID: <6a8523d60910191927l59e0eaa3wd29f603aa3936579@mail.gmail.com>

There have been a couple problems recently, but I don't recognize
this. Please see if you can minimize it and get a test case.

You can run with 'make VERBOSE=1' to get the failing compile command.
I then usually try -emit-llvm to see if the .bc output reproduces the
error (with llc). The full story is a lot more complicated, I can give
more details about things to try if you can't get a test case.

 - Daniel

On Mon, Oct 19, 2009 at 7:03 PM, John Regehr <regehr at cs.utah.edu> wrote:
> I've been getting the error for a release build for the last 24 hours or
> so. ? This is on Ubuntu Jaunty on x86. ?Known problem? ?If not, does
> anyone have an easy recipe for getting the build system to tell me the
> command line that's being used and to leave a preprocessed file sitting
> around?
>
> Thanks,
>
> John
>
>
> llvm[2]: Compiling UnreachableBlockElim.cpp for Release build
> StrongPHIElimination.cpp: In member function '(anonymous
> namespace)::StrongPHIElimination::InsertCopies(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*,
> llvm::SmallPtrSet<llvm::MachineBasicBlock*, 16u>&)':
> StrongPHIElimination.cpp:1051:1: internal compiler error: in
> rewrite_stmt, at tree-into-ssa.c:1302
> Please submit a full bug report,
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


From lhames at gmail.com  Mon Oct 19 21:28:56 2009
From: lhames at gmail.com (Lang Hames)
Date: Mon, 19 Oct 2009 19:28:56 -0700
Subject: [LLVMdev] request for help writing a register allocator
In-Reply-To: <E2113887-CA1A-41E8-848C-794E629196BB@apple.com>
References: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
	<E2113887-CA1A-41E8-848C-794E629196BB@apple.com>
Message-ID: <728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>

Hi Susan,

> You may find the PBQP allocator implementation useful as a reference
> to what's involved in adding a new allocator to LLVM. It's located in
> lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/CodeGen/
> PBQP directory.
>

Yes - as far as working allocators go PBQP is pretty simple. If you're just
interested in LLVM API details you can focus on the lower half of the
RegAllocPBQP.cpp source file (everything
from PBQPRegAlloc::findVRegIntervalsToAlloc()). The rest of the source
(class declaration at the top of RegAllocPBQP.cpp aside) is mostly concerned
with PBQP algorithm specifics, such as constructing cost matrices, or
carrying out the PBQP graph reduction algorithm.


> > Is there anyone who has written an LLVM register allocator who would
> > be
> > willing to help me understand the basic ideas?  I understand the
> > algorithm, it's LLVM that I don't understand.  For example:
> >
> > - When allocating registers, how do I know which register class to
> > use,
> >   and which registers of that class are available?
>

For each virtual register the MachineRegisterInfo::getRegClass(<vreg>)
method will give you a TargetRegisterClass. You can use the
allocation_order_begin/allocation_order_end methods to iterate over the
allocable physregs in that class.


> > - How do I know which operands of a Machine Instruction are candidates
> >   for (simple) register allocation (e.g., are of type int)?
>

Each operand of a MachineInstr has a corresponding MachineOperand object.
You can query this object using the "isReg()" method to check if an operand
is a register. You'd then have to use
"TargetRegisterInfo::isVirtualRegister(<reg>)" to test whether the operand
is virtual, and from there perform your allocation.

I've attached a demo allocator that'll get you started with the above APIs.

LLVM's CodeGen library is target independent though, and the register
allocator is expected to be able to allocate for _all_ virtregs, regardless
of their class (and to handle things like register aliasing). There's no
built-in distinction of "simple" candidates, as opposed to trickier ones.

If it helps you could hard code a test for your chosen platform (presumably
something nice and clean) at the start of the allocator, and from there on
work on the assumption that you're dealing with that platform. Then it'd be
up to you to decide which classes the students would have to allocate for.
You'd still need a way to allocate any "hard" classes though if you want a
working program.


> > - How do I replace a virtual register with a physical one?
>
> - Do I need to generate spill code to handle virtual registers that
>
>   cannot be replaced with physical ones, and if so, how?
>

You could re-write it in place (using MachineRegisterOperand::setReg(<reg>)
if you want to manipulate the code yourself, or you can store the mapping in
a VirtRegMap object and have the LLVM VirtRegRewriter apply the changes for
you. The latter would have to be used in conjunction with the other LLVM
regalloc components. You'd get liveness (LiveIntervals) and spilling
(LiveIntervals/VirtRegRewriter) for free, at the cost of some extra work to
understand their somewhat curious APIs. Looking at RegAllocPBQP.cpp is
probably the best way to get your head around how those components are used
by register allocation.


Regards,
Lang Hames.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/732ab805/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RegAllocDemo.cpp
Type: application/octet-stream
Size: 5743 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/732ab805/attachment.obj 

From espindola at google.com  Mon Oct 19 22:03:55 2009
From: espindola at google.com (Rafael Espindola)
Date: Mon, 19 Oct 2009 23:03:55 -0400
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <1255999226.6513.8.camel@UIUC>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC> <4ADA7F0D.4050107@mxc.ca>
	<1255833619.23327.15.camel@UIUC>
	<38a0d8450910191058k552b003fo1d25654430df463c@mail.gmail.com>
	<1255999226.6513.8.camel@UIUC>
Message-ID: <38a0d8450910192003x9455b0dj4bf7b7935ffd13ad@mail.gmail.com>

2009/10/19 zhunan <zhunansjtu at gmail.com>:
> Yes,but when I just simply replace lto_codegen_compile(cg, ...) with
> lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the
> gold-plugin.cpp to see if it will generate a correct bc file,the
> llvm-gcc/llvm-g++ will call the native ld in the linking step,which
> causes the failture because of that ld can not recognize an object file
> which contains LLVM's IL.

The plugin is running *in* the native linker. What you want to do is
add an option in the plugin to write the bc file to an specified file
*in addition* to producing a regular elf object. This way the build
will complete correctly and you will get the .bc file you want.

> I understand the failture as this: libLLVMgold.so is just a plugin for
> ld but not llvm-ld,when I want to build a whole-program bitcodes,llvm-ld
> is the only available tool,so I think gold-plugin is not very useful to
> archieve the goal,I'm considering to modify the codes of llvm-gcc's
> collect2 to make it call llvm-ld automatically when receive certain
> options.

It will probably be hard to get this to work correctly with archives
and shared libraries. In 4.5 gcc we have a hacked collect2 for
people using lto and gnu ld.

> Thanks
>

Cheers,
-- 
Rafael ?vila de Esp?ndola


From regehr at cs.utah.edu  Mon Oct 19 22:10:38 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 19 Oct 2009 21:10:38 -0600 (MDT)
Subject: [LLVMdev] self-hosting failure
In-Reply-To: <6a8523d60910191927l59e0eaa3wd29f603aa3936579@mail.gmail.com>
References: <4ADD1A87.1010106@cs.utah.edu>
	<6a8523d60910191927l59e0eaa3wd29f603aa3936579@mail.gmail.com>
Message-ID: <alpine.DEB.1.00.0910192101530.13053@memphis.cs.utah.edu>

Of course my next build worked!

Anyway thanks guys.  I'll use this recipe next time I see a problem like 
this...

John



On Mon, 19 Oct 2009, Daniel Dunbar wrote:

> There have been a couple problems recently, but I don't recognize
> this. Please see if you can minimize it and get a test case.
>
> You can run with 'make VERBOSE=1' to get the failing compile command.
> I then usually try -emit-llvm to see if the .bc output reproduces the
> error (with llc). The full story is a lot more complicated, I can give
> more details about things to try if you can't get a test case.
>
> - Daniel
>
> On Mon, Oct 19, 2009 at 7:03 PM, John Regehr <regehr at cs.utah.edu> wrote:
>> I've been getting the error for a release build for the last 24 hours or
>> so. ? This is on Ubuntu Jaunty on x86. ?Known problem? ?If not, does
>> anyone have an easy recipe for getting the build system to tell me the
>> command line that's being used and to leave a preprocessed file sitting
>> around?
>>
>> Thanks,
>>
>> John
>>
>>
>> llvm[2]: Compiling UnreachableBlockElim.cpp for Release build
>> StrongPHIElimination.cpp: In member function '(anonymous
>> namespace)::StrongPHIElimination::InsertCopies(llvm::DomTreeNodeBase<llvm::MachineBasicBlock>*,
>> llvm::SmallPtrSet<llvm::MachineBasicBlock*, 16u>&)':
>> StrongPHIElimination.cpp:1051:1: internal compiler error: in
>> rewrite_stmt, at tree-into-ssa.c:1302
>> Please submit a full bug report,
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>

From lhames at gmail.com  Mon Oct 19 22:15:42 2009
From: lhames at gmail.com (Lang Hames)
Date: Mon, 19 Oct 2009 20:15:42 -0700
Subject: [LLVMdev] request for help writing a register allocator
In-Reply-To: <728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>
References: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
	<E2113887-CA1A-41E8-848C-794E629196BB@apple.com>
	<728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>
Message-ID: <728927c70910192015q575d3c2fm33b284eaa51169f6@mail.gmail.com>

? correction:


> You could re-write it in place (using
> MachineRegisterOperand::setReg(<reg>)...
>

That should have been MachineOperand::setReg(<reg>)...

And a disclaimer:
I wrote the PBQP allocator, so I might be biased. I think it's easier to
follow than linear scan though.

- Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/1d315fc9/attachment.html 

From regehr at cs.utah.edu  Mon Oct 19 22:47:11 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Mon, 19 Oct 2009 21:47:11 -0600 (MDT)
Subject: [LLVMdev] slooow compiles
Message-ID: <alpine.DEB.1.00.0910192115560.15430@memphis.cs.utah.edu>

As part of routine testing, I run clang and llvm-gcc a lot of times. 
Something happened between r83681 and r84167 such that clang-cc and cc1 
became many hundreds of times slower when asked to perform optimizations.

Is this a known issue?  These are all release builds on Ubuntu Jaunty on 
x86.  During these long runs, memory usage creeps up slowly at maybe 1 MB 
per minute.

Thanks,

John Regehr

From zhunansjtu at gmail.com  Mon Oct 19 23:16:06 2009
From: zhunansjtu at gmail.com (zhunan)
Date: Tue, 20 Oct 2009 12:16:06 +0800
Subject: [LLVMdev] strace for whole-program bitcodes
In-Reply-To: <38a0d8450910192003x9455b0dj4bf7b7935ffd13ad@mail.gmail.com>
References: <mailman.9.1255712401.308.llvmdev@cs.uiuc.edu>
	<1255832369.23327.10.camel@UIUC> <4ADA7F0D.4050107@mxc.ca>
	<1255833619.23327.15.camel@UIUC>
	<38a0d8450910191058k552b003fo1d25654430df463c@mail.gmail.com>
	<1255999226.6513.8.camel@UIUC>
	<38a0d8450910192003x9455b0dj4bf7b7935ffd13ad@mail.gmail.com>
Message-ID: <1256012166.6334.0.camel@UIUC>

OK,thanks for the help!

I'll try it later!

Best regards!

? 2009-10-19?? 23:03 -0400?Rafael Espindola???
> 2009/10/19 zhunan <zhunansjtu at gmail.com>:
> > Yes,but when I just simply replace lto_codegen_compile(cg, ...) with
> > lto_codegen_write_merged_modules(cg, "/path/to/output.bc") in the
> > gold-plugin.cpp to see if it will generate a correct bc file,the
> > llvm-gcc/llvm-g++ will call the native ld in the linking step,which
> > causes the failture because of that ld can not recognize an object file
> > which contains LLVM's IL.
> 
> The plugin is running *in* the native linker. What you want to do is
> add an option in the plugin to write the bc file to an specified file
> *in addition* to producing a regular elf object. This way the build
> will complete correctly and you will get the .bc file you want.
> 
> > I understand the failture as this: libLLVMgold.so is just a plugin for
> > ld but not llvm-ld,when I want to build a whole-program bitcodes,llvm-ld
> > is the only available tool,so I think gold-plugin is not very useful to
> > archieve the goal,I'm considering to modify the codes of llvm-gcc's
> > collect2 to make it call llvm-ld automatically when receive certain
> > options.
> 
> It will probably be hard to get this to work correctly with archives
> and shared libraries. In 4.5 gcc we have a hacked collect2 for
> people using lto and gnu ld.
> 
> > Thanks
> >
> 
> Cheers,


From gohman at apple.com  Mon Oct 19 23:24:28 2009
From: gohman at apple.com (Dan Gohman)
Date: Mon, 19 Oct 2009 21:24:28 -0700
Subject: [LLVMdev] slooow compiles
In-Reply-To: <alpine.DEB.1.00.0910192115560.15430@memphis.cs.utah.edu>
References: <alpine.DEB.1.00.0910192115560.15430@memphis.cs.utah.edu>
Message-ID: <4AA5EA99-70F5-4C33-8683-66782C75DD5C@apple.com>

My InlineCost refactoring has been noticed in this aspect; that may or  
may notbe the culprit here.

A quick thing you can do is to compile with -ftime-report and compare  
the top few passes between versions.

Dan

On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote:

> As part of routine testing, I run clang and llvm-gcc a lot of times.
> Something happened between r83681 and r84167 such that clang-cc and  
> cc1
> became many hundreds of times slower when asked to perform  
> optimizations.
>
> Is this a known issue?  These are all release builds on Ubuntu  
> Jaunty on
> x86.  During these long runs, memory usage creeps up slowly at maybe  
> 1 MB
> per minute.
>
> Thanks,
>
> John Regehr
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From clattner at apple.com  Mon Oct 19 23:34:33 2009
From: clattner at apple.com (Chris Lattner)
Date: Mon, 19 Oct 2009 21:34:33 -0700
Subject: [LLVMdev] request for help writing a register allocator
In-Reply-To: <728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>
References: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
	<E2113887-CA1A-41E8-848C-794E629196BB@apple.com>
	<728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>
Message-ID: <66175350-505A-4DAB-9150-8BA27C42A761@apple.com>


On Oct 19, 2009, at 7:28 PM, Lang Hames wrote:

> Hi Susan,
>
> You may find the PBQP allocator implementation useful as a reference
> to what's involved in adding a new allocator to LLVM. It's located in
> lib/CodeGen/RegAllocPBQP.cpp, with supporting files in the lib/ 
> CodeGen/
> PBQP directory.
>
> Yes - as far as working allocators go PBQP is pretty simple. If  
> you're just interested in LLVM API details you can focus on the  
> lower half of the RegAllocPBQP.cpp source file (everything from  
> PBQPRegAlloc::findVRegIntervalsToAlloc()). The rest of the source  
> (class declaration at the top of RegAllocPBQP.cpp aside) is mostly  
> concerned with PBQP algorithm specifics, such as constructing cost  
> matrices, or carrying out the PBQP graph reduction algorithm.

Other advice: if you're looking to simplify this for students, I'd  
recommend staying away from X86 or ARM, which use subregs heavily.  If  
you work with (e.g.) the sparc backend, you can avoid them completely,  
simplifying the problem.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091019/d3cb91f1/attachment.html 

From zhu.heyu at gmail.com  Tue Oct 20 00:44:35 2009
From: zhu.heyu at gmail.com (Heyu Zhu)
Date: Tue, 20 Oct 2009 13:44:35 +0800
Subject: [LLVMdev] Problem when build LLVM
Message-ID: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>

Hi,

 When i make LLVM with llvm-2.5.tar.gz an error  occurs. The step is below

tar -zxvf llvm-2.5.tar.gz
cd llvm-2.5-tar.gz
make ENABLE_OPTIMIZED=1

Then then the  error is:

/tools/IUS611/tools/lib/libgcc_s.so.1: version `GCC_4.2.0' not found
(required by /usr/lib/libstdc++.so.6)

What shall i do to avoid it?

I am a newbie, maybe it's a foolish question

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/7782a611/attachment.html 

From zhu.heyu at gmail.com  Tue Oct 20 01:31:52 2009
From: zhu.heyu at gmail.com (Heyu Zhu)
Date: Tue, 20 Oct 2009 14:31:52 +0800
Subject: [LLVMdev] Problem when build LLVM
In-Reply-To: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
Message-ID: <f41e75510910192331h1415e689m4d6062dddd40d3b4@mail.gmail.com>

After reading //llvm.org/PR896 i make it again as below step

configure --disable-shared
make ENABLE_OPTIMIZED=1

It still reports same error message



2009/10/20, Heyu Zhu <zhu.heyu at gmail.com>:
>
> Hi,
>
>  When i make LLVM with llvm-2.5.tar.gz an error  occurs. The step is below
>
> tar -zxvf llvm-2.5.tar.gz
> cd llvm-2.5-tar.gz
> make ENABLE_OPTIMIZED=1
>
> Then then the  error is:
>
> /tools/IUS611/tools/lib/libgcc_s.so.1: version `GCC_4.2.0' not found
> (required by /usr/lib/libstdc++.so.6)
>
> What shall i do to avoid it?
>
> I am a newbie, maybe it's a foolish question
>
> Regards
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/ec965e7d/attachment.html 

From baldrick at free.fr  Tue Oct 20 02:16:04 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 09:16:04 +0200
Subject: [LLVMdev] Using address space attribute in LLVM
In-Reply-To: <8BF3A409-9C39-48B6-A3BC-5A6A5BB29FCC@apple.com>
References: <d17b77a40910190840p1d5e4d16g92f33f8316409b9@mail.gmail.com>
	<8BF3A409-9C39-48B6-A3BC-5A6A5BB29FCC@apple.com>
Message-ID: <4ADD63B4.5080304@free.fr>

> llvm-gcc doesn't support address spaces.  This is a clang-only feature.

However it could be implemented in llvm-gcc.

Ciao,

Duncan.

From baldrick at free.fr  Tue Oct 20 02:32:29 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 09:32:29 +0200
Subject: [LLVMdev] Problem when build LLVM
In-Reply-To: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
Message-ID: <4ADD678D.9090209@free.fr>

Hi Heyu Zhu,

> Then then the  error is:
>  
> /tools/IUS611/tools/lib/libgcc_s.so.1: version `GCC_4.2.0' not found 
> (required by /usr/lib/libstdc++.so.6)

you can get this if you compile C++ code using a different compiler to
your system compiler.  Based on the error message, your system compiler
is gcc-4.2 and the other compiler is probably gcc-4.3 or later.  What
has happened is that LLVM has been linked using the system libstdc++,
which is from gcc-4.2, and which requires libgcc from the same version
of gcc, namely gcc-4.2.  However it is getting libgcc from the other
compiler and complaining.  What you need to do is to link with the
version of libstdc++ that came with the other compiler.

Ciao,

Duncan.

From pietreka at gmail.com  Tue Oct 20 03:27:29 2009
From: pietreka at gmail.com (Artur Pietrek)
Date: Tue, 20 Oct 2009 10:27:29 +0200
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
In-Reply-To: <D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>
References: <4ADBD4E3.5090106@gmail.com>
	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
	<400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>
	<D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>
Message-ID: <d50b8be20910200127k7fe31ca1g405fe51c2a85dd5e@mail.gmail.com>

Hi Jean-Daniel

On Mon, Oct 19, 2009 at 3:24 PM, Jean-Daniel Dupas
<devlists at shadowlab.org>wrote:

>
> Le 19 oct. 2009 ? 15:05, Kenneth Uildriks a ?crit :
> FWIW, there is a LLVM bar camp planed in Paris the next month:
>
> http://barcamp.org/LLVM%20BarCamp%20Paris (French web page)
>
>
> -- Jean-Daniel
>

Could you please tell me if it will be in French or English? Currently I
live in France so I'd like to come, but my French is still work in progress.

Thanks,
Artur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/c4dc3646/attachment.html 

From devlists at shadowlab.org  Tue Oct 20 03:36:16 2009
From: devlists at shadowlab.org (Jean-Daniel Dupas)
Date: Tue, 20 Oct 2009 10:36:16 +0200
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
In-Reply-To: <d50b8be20910200127k7fe31ca1g405fe51c2a85dd5e@mail.gmail.com>
References: <4ADBD4E3.5090106@gmail.com>
	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
	<400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>
	<D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>
	<d50b8be20910200127k7fe31ca1g405fe51c2a85dd5e@mail.gmail.com>
Message-ID: <B97FA892-1809-4043-8E00-AA500D61BFA7@shadowlab.org>


Le 20 oct. 2009 ? 10:27, Artur Pietrek a ?crit :

> Hi Jean-Daniel
>
> On Mon, Oct 19, 2009 at 3:24 PM, Jean-Daniel Dupas <devlists at shadowlab.org 
> > wrote:
>
> Le 19 oct. 2009 ? 15:05, Kenneth Uildriks a ?crit :
> FWIW, there is a LLVM bar camp planed in Paris the next month:
>
> http://barcamp.org/LLVM%20BarCamp%20Paris (French web page)
>
>
> -- Jean-Daniel
>
> Could you please tell me if it will be in French or English?  
> Currently I live in France so I'd like to come, but my French is  
> still work in progress.
>
> Thanks,
> Artur

Sorry, I'm not involved in any way in this event, but feel free to  
contact the planner: Eric Mah? (eric at ericmahe dot com)

-- Jean-Daniel






From pietreka at gmail.com  Tue Oct 20 04:04:36 2009
From: pietreka at gmail.com (Artur Pietrek)
Date: Tue, 20 Oct 2009 11:04:36 +0200
Subject: [LLVMdev] Opportunities for meeting more frequently than once a
	year?
In-Reply-To: <B97FA892-1809-4043-8E00-AA500D61BFA7@shadowlab.org>
References: <4ADBD4E3.5090106@gmail.com>
	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>
	<400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>
	<D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>
	<d50b8be20910200127k7fe31ca1g405fe51c2a85dd5e@mail.gmail.com>
	<B97FA892-1809-4043-8E00-AA500D61BFA7@shadowlab.org>
Message-ID: <d50b8be20910200204q156d0d0ata07c0172e2fa84f2@mail.gmail.com>

Hi,
So for everybody who could be interested in LLVM Camp in Paris - it will be
in French.
I've just received an email from Eric Mah?.

Artur


On Tue, Oct 20, 2009 at 10:36 AM, Jean-Daniel Dupas
<devlists at shadowlab.org>wrote:

>
> Le 20 oct. 2009 ? 10:27, Artur Pietrek a ?crit :
>
>  Hi Jean-Daniel
>>
>> On Mon, Oct 19, 2009 at 3:24 PM, Jean-Daniel Dupas <
>> devlists at shadowlab.org> wrote:
>>
>> Le 19 oct. 2009 ? 15:05, Kenneth Uildriks a ?crit :
>> FWIW, there is a LLVM bar camp planed in Paris the next month:
>>
>> http://barcamp.org/LLVM%20BarCamp%20Paris (French web page)
>>
>>
>> -- Jean-Daniel
>>
>> Could you please tell me if it will be in French or English? Currently I
>> live in France so I'd like to come, but my French is still work in progress.
>>
>> Thanks,
>> Artur
>>
>
> Sorry, I'm not involved in any way in this event, but feel free to contact
> the planner: Eric Mah? (eric at ericmahe dot com)
>
> -- Jean-Daniel
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/9aea75eb/attachment.html 

From da.waterworth at googlemail.com  Tue Oct 20 04:31:31 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 10:31:31 +0100
Subject: [LLVMdev] Dereference PointerType?
Message-ID: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>

Hello,

I'm wondering if it's possible to dereference a PointerType. I have an
AllocaInst and although I can find the number of elements allocated, (using
Instruction::getOperand(0)), I can't find a way to get the size of each
element. What I'd like to do is:

AllocaInst *alloca;

PointerType *ptr_type = dynamic_cast<PointerType*>(alloca);
assert(ptr_type);
Type *allocated_type = ptr_type->dereference(); // this is the operation
that doesn't seem to exist.
size_t size;
if (isa<PointerType>(allocated_type)) {
  size = sizeof(void*) * 8;
} else {
  size = allocated_type->getPrimitiveSizeInBits();
}
// size now equals the size (in bits) of the type allocated

If it doesn't exist, how do you manage without it? Is there another way to
write the above code?

Thanks,

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/a35e4e62/attachment.html 

From zhu.heyu at gmail.com  Tue Oct 20 04:33:09 2009
From: zhu.heyu at gmail.com (Heyu Zhu)
Date: Tue, 20 Oct 2009 17:33:09 +0800
Subject: [LLVMdev] Problem when build LLVM
In-Reply-To: <4ADD678D.9090209@free.fr>
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
	<4ADD678D.9090209@free.fr>
Message-ID: <f41e75510910200233v5fa7d8fbpc16638facf520463@mail.gmail.com>

According to your description i should not use the system libstdc++ and i
need to
specify the OTHER compiler libstdc++. But i don't where the OTHER compiler
libstdc++ is.
Is the  OTHER compiler libstdc++ contained in llvm-2.5.tar.gz? if not where
can i get it?



2009/10/20, Duncan Sands <baldrick at free.fr>:
>
> Hi Heyu Zhu,
>
> Then then the  error is:
>>  /tools/IUS611/tools/lib/libgcc_s.so.1: version `GCC_4.2.0' not found
>> (required by /usr/lib/libstdc++.so.6)
>>
>
> you can get this if you compile C++ code using a different compiler to
> your system compiler.  Based on the error message, your system compiler
> is gcc-4.2 and the other compiler is probably gcc-4.3 or later.  What
> has happened is that LLVM has been linked using the system libstdc++,
> which is from gcc-4.2, and which requires libgcc from the same version
> of gcc, namely gcc-4.2.  However it is getting libgcc from the other
> compiler and complaining.  What you need to do is to link with the
> version of libstdc++ that came with the other compiler.
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/235345dd/attachment.html 

From da.waterworth at googlemail.com  Tue Oct 20 04:39:58 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 10:39:58 +0100
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
Message-ID: <7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>

2009/10/20 Daniel Waterworth <da.waterworth at googlemail.com>

> Hello,
>
> I'm wondering if it's possible to dereference a PointerType. I have an
> AllocaInst and although I can find the number of elements allocated, (using
> Instruction::getOperand(0)), I can't find a way to get the size of each
> element. What I'd like to do is:
>
> AllocaInst *alloca;
>
> PointerType *ptr_type = dynamic_cast<PointerType*>(alloca);
> assert(ptr_type);
> Type *allocated_type = ptr_type->dereference(); // this is the operation
> that doesn't seem to exist.
> size_t size;
> if (isa<PointerType>(allocated_type)) {
>   size = sizeof(void*) * 8;
> } else {
>   size = allocated_type->getPrimitiveSizeInBits();
> }
> // size now equals the size (in bits) of the type allocated
>
> If it doesn't exist, how do you manage without it? Is there another way to
> write the above code?
>
> Thanks,
>
> Daniel
>

Spot the deliberate mistake [=

PointerType *ptr_type = dynamic_cast<PointerType*>(alloca);

should be,

const PointerType *ptr_type = dynamic_cast<const
PointerType*>(alloca->getType());

and,

Type *allocated_type = ptr_type->dereference();

should probably be,

const Type *allocated_type = ptr_type->dereference();

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/5ea65e1d/attachment.html 

From baldrick at free.fr  Tue Oct 20 04:25:44 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 11:25:44 +0200
Subject: [LLVMdev] Opportunities for meeting more frequently than once
 a	year?
In-Reply-To: <d50b8be20910200204q156d0d0ata07c0172e2fa84f2@mail.gmail.com>
References: <4ADBD4E3.5090106@gmail.com>	<14408EA0-089C-4617-87A4-65223EFDE4E1@apple.com>	<400d33ea0910190605r16a85b88pf514a83e0ac86438@mail.gmail.com>	<D939DA09-2490-4019-8D37-7B36D3476289@shadowlab.org>	<d50b8be20910200127k7fe31ca1g405fe51c2a85dd5e@mail.gmail.com>	<B97FA892-1809-4043-8E00-AA500D61BFA7@shadowlab.org>
	<d50b8be20910200204q156d0d0ata07c0172e2fa84f2@mail.gmail.com>
Message-ID: <4ADD8218.6030400@free.fr>

> So for everybody who could be interested in LLVM Camp in Paris - it will 
> be in French.

Probably many people there speak English, so it may still be worth going
just to chat with people about LLVM.

Ciao,

Duncan.

From ofv at wanadoo.es  Tue Oct 20 05:23:19 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 20 Oct 2009 12:23:19 +0200
Subject: [LLVMdev] Dereference PointerType?
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
Message-ID: <87pr8i8iug.fsf@telefonica.net>

Daniel Waterworth <da.waterworth at googlemail.com> writes:

[snip]

Use the getElementType method of PointerType.

>> size_t size;
>> if (isa<PointerType>(allocated_type)) {
>>   size = sizeof(void*) * 8;
>> } else {
>>   size = allocated_type->getPrimitiveSizeInBits();
>> }
>> // size now equals the size (in bits) of the type allocated

This looks suspicious to me. Maybe you intented

if (isa<PointerType>(allocated_type)) {
  size = sizeof(void*);
} else {
  size = allocated_type->getPrimitiveSizeInBits() * 8;
}

but take a look at getPrimitiveSizeInBits' documentation to make sure
that it is really what you want:

http://llvm.org/doxygen/classllvm_1_1Type.html

-- 
?scar


From ofv at wanadoo.es  Tue Oct 20 05:29:33 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 20 Oct 2009 12:29:33 +0200
Subject: [LLVMdev] Problem when build LLVM
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
	<4ADD678D.9090209@free.fr>
	<f41e75510910200233v5fa7d8fbpc16638facf520463@mail.gmail.com>
Message-ID: <87k4yq8ik2.fsf@telefonica.net>

Heyu Zhu <zhu.heyu at gmail.com> writes:

> According to your description i should not use the system libstdc++
> and i need to specify the OTHER compiler libstdc++. But i don't where
> the OTHER compiler libstdc++ is.  Is the OTHER compiler libstdc++
> contained in llvm-2.5.tar.gz? if not where can i get it?

g++ should use the right libstdc++ automatically. If it doesn't, most
probable cause is a defective installation.

Start by compiling a simple C++ program like this:

#include <iostream>

int main() {
    std::cout << "Hello!";
}

(compile it with g++)

If that fails with the same error, you need to fix your C++ setup. A
forum or mailing list of gcc users is the right place for helping you on
that.

-- 
?scar


From baldrick at free.fr  Tue Oct 20 05:43:39 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 12:43:39 +0200
Subject: [LLVMdev] Problem when build LLVM
In-Reply-To: <f41e75510910200233v5fa7d8fbpc16638facf520463@mail.gmail.com>
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>	<4ADD678D.9090209@free.fr>
	<f41e75510910200233v5fa7d8fbpc16638facf520463@mail.gmail.com>
Message-ID: <4ADD945B.9000209@free.fr>

Hi Heyu Zhu,

> According to your description i should not use the system libstdc++ and 
> i need to
> specify the OTHER compiler libstdc++. But i don't where the OTHER compiler
> libstdc++ is.
> Is the  OTHER compiler libstdc++ contained in llvm-2.5.tar.gz? if not 
> where can i get it?

this has nothing to do with llvm, you would have the same problem with
any C++ code that uses the C++ standard library.  As far as I can see
you have installed a second compiler under /tools/IUS611/tools/.  Try
looking for libstdc++ in /tools/IUS611/tools/lib.

Ciao,

Duncan.

From baldrick at free.fr  Tue Oct 20 05:44:51 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 12:44:51 +0200
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
Message-ID: <4ADD94A3.7040908@free.fr>

Hi Daniel,

>     Type *allocated_type = ptr_type->dereference(); // this is the
>     operation that doesn't seem to exist.

Type *allocated_type = ptr_type->getElementType();

Ciao,

Duncan.

From da.waterworth at googlemail.com  Tue Oct 20 05:51:25 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 11:51:25 +0100
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <4ADD94A3.7040908@free.fr>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<4ADD94A3.7040908@free.fr>
Message-ID: <7a5a555b0910200351p79fc8054t488d72c52c5c0164@mail.gmail.com>

I can't believe I missed it. I think I must have forgotten to look at
SequentialType when I was searching through the API docs.

Thanks very much,

Daniel

2009/10/20 Duncan Sands <baldrick at free.fr>

> Hi Daniel,
>
>     Type *allocated_type = ptr_type->dereference(); // this is the
>>    operation that doesn't seem to exist.
>>
>
> Type *allocated_type = ptr_type->getElementType();
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/51ecda81/attachment.html 

From zhu.heyu at gmail.com  Tue Oct 20 06:01:04 2009
From: zhu.heyu at gmail.com (Heyu Zhu)
Date: Tue, 20 Oct 2009 19:01:04 +0800
Subject: [LLVMdev] Problem when build llvm-gcc using
	llvm-gcc-4.2-2.5.source.tar.gz
Message-ID: <f41e75510910200401ua37e5bcuca03559d95e4c308@mail.gmail.com>

The error message is :
cc1plus:error: unrecognzied command line option -Wno-variadic-macros

What's the reason?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/04c6925a/attachment.html 

From baldrick at free.fr  Tue Oct 20 06:02:56 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 13:02:56 +0200
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <87pr8i8iug.fsf@telefonica.net>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<87pr8i8iug.fsf@telefonica.net>
Message-ID: <4ADD98E0.5020303@free.fr>

?scar Fuentes wrote:
> Daniel Waterworth <da.waterworth at googlemail.com> writes:
> 
> [snip]
> 
> Use the getElementType method of PointerType.
> 
>>> size_t size;
>>> if (isa<PointerType>(allocated_type)) {
>>>   size = sizeof(void*) * 8;
>>> } else {
>>>   size = allocated_type->getPrimitiveSizeInBits();
>>> }
>>> // size now equals the size (in bits) of the type allocated
> 
> This looks suspicious to me.

Probably he wants getTypeAllocSize (available from target data).  The
special casing of PointerType is both useless and bogus.

Ciao,

Duncan.

From jay.foad at gmail.com  Tue Oct 20 06:24:00 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Oct 2009 12:24:00 +0100
Subject: [LLVMdev] [cfe-dev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>

> 2.6 pre-release2 is ready to be tested by the community.

Excellent! Would you care to update the "LLVM 2.6 release schedule" on
the front page of the web site?

Thanks,
Jay.

From da.waterworth at googlemail.com  Tue Oct 20 06:25:41 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 12:25:41 +0100
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <4ADD98E0.5020303@free.fr>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<87pr8i8iug.fsf@telefonica.net> <4ADD98E0.5020303@free.fr>
Message-ID: <7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>

It may not be the best way to do what I'm trying to do, but it's not useless
and bogus. Consider the following:

%1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32*
and
                         ; the size of that is sizeof(void *) bytes

Having said that I am looking at the target data getTypeAllocSize method.

Daniel

2009/10/20 Duncan Sands <baldrick at free.fr>

> ?scar Fuentes wrote:
>
>> Daniel Waterworth <da.waterworth at googlemail.com> writes:
>>
>> [snip]
>>
>> Use the getElementType method of PointerType.
>>
>>  size_t size;
>>>> if (isa<PointerType>(allocated_type)) {
>>>>  size = sizeof(void*) * 8;
>>>> } else {
>>>>  size = allocated_type->getPrimitiveSizeInBits();
>>>> }
>>>> // size now equals the size (in bits) of the type allocated
>>>>
>>>
>> This looks suspicious to me.
>>
>
> Probably he wants getTypeAllocSize (available from target data).  The
> special casing of PointerType is both useless and bogus.
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/9ae51bb3/attachment.html 

From ofv at wanadoo.es  Tue Oct 20 06:54:26 2009
From: ofv at wanadoo.es (=?windows-1252?Q?=D3scar_Fuentes?=)
Date: Tue, 20 Oct 2009 13:54:26 +0200
Subject: [LLVMdev] Dereference PointerType?
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<87pr8i8iug.fsf@telefonica.net> <4ADD98E0.5020303@free.fr>
	<7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>
Message-ID: <87bpk28eml.fsf@telefonica.net>

Daniel Waterworth <da.waterworth at googlemail.com> writes:

> It may not be the best way to do what I'm trying to do, but it's not useless
> and bogus. Consider the following:
>
> %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type i32*
> and
>                          ; the size of that is sizeof(void *) bytes

What Duncan says is that any valid method for obtaining the size of a
Type should work for a PointerType, which is just another kind of Type.

>>>>> if (isa<PointerType>(allocated_type)) {
>>>>>  size = sizeof(void*) * 8;
>>>>> } else {
>>>>>  size = allocated_type->getPrimitiveSizeInBits();
>>>>> }
>>>>> // size now equals the size (in bits) of the type allocated

-- 
?scar


From da.waterworth at googlemail.com  Tue Oct 20 07:11:49 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 13:11:49 +0100
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <87bpk28eml.fsf@telefonica.net>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<87pr8i8iug.fsf@telefonica.net> <4ADD98E0.5020303@free.fr>
	<7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>
	<87bpk28eml.fsf@telefonica.net>
Message-ID: <7a5a555b0910200511g3487f482w8c25a9885f9e370f@mail.gmail.com>

I agree, however, I didn't realise there was another method for obtaining
the size until Duncan, correctly, pointed one out. I have since changed my
code to use the getAllocSize method.

Thanks,

Daniel

2009/10/20 ?scar Fuentes <ofv at wanadoo.es>

> Daniel Waterworth <da.waterworth at googlemail.com> writes:
>
> > It may not be the best way to do what I'm trying to do, but it's not
> useless
> > and bogus. Consider the following:
> >
> > %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type
> i32*
> > and
> >                          ; the size of that is sizeof(void *) bytes
>
> What Duncan says is that any valid method for obtaining the size of a
> Type should work for a PointerType, which is just another kind of Type.
>
> >>>>> if (isa<PointerType>(allocated_type)) {
> >>>>>  size = sizeof(void*) * 8;
> >>>>> } else {
> >>>>>  size = allocated_type->getPrimitiveSizeInBits();
> >>>>> }
> >>>>> // size now equals the size (in bits) of the type allocated
>
> --
> ?scar
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/94fe705c/attachment-0001.html 

From baldrick at free.fr  Tue Oct 20 07:20:11 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 14:20:11 +0200
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>	
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>	
	<87pr8i8iug.fsf@telefonica.net> <4ADD98E0.5020303@free.fr>
	<7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>
Message-ID: <4ADDAAFB.1010903@free.fr>

Hi Daniel,

> It may not be the best way to do what I'm trying to do, but it's not 
> useless and bogus. Consider the following:
> 
> %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type 
> i32* and
>                          ; the size of that is sizeof(void *) bytes

it is useless because getTypeAllocSize will handle any type, including
pointer types.  It is bogus because your code assumes that the LLVM
bitcode is targeting your own machine, i.e. that sizeof(void*) as given
by your machine is correct for the target.  This may or may not be the
case, but it is something best avoided.

Ciao,

Duncan.

From da.waterworth at googlemail.com  Tue Oct 20 07:31:50 2009
From: da.waterworth at googlemail.com (Daniel Waterworth)
Date: Tue, 20 Oct 2009 13:31:50 +0100
Subject: [LLVMdev] Dereference PointerType?
In-Reply-To: <4ADDAAFB.1010903@free.fr>
References: <7a5a555b0910200231u8ae4366i2256386324f69665@mail.gmail.com>
	<7a5a555b0910200239m1378a6a1kb7c5df33e3fa44d5@mail.gmail.com>
	<87pr8i8iug.fsf@telefonica.net> <4ADD98E0.5020303@free.fr>
	<7a5a555b0910200425h5fb0ad78jc3444f54d11b716a@mail.gmail.com>
	<4ADDAAFB.1010903@free.fr>
Message-ID: <7a5a555b0910200531t1d9aa1f0n187bf8e72edc90a6@mail.gmail.com>

I'm writing a function pass that is run before an ExecutionEngine Jit's the
code. Therefore I can assume that my machine is the correct target. It is
never the case that the pass would be run and then stored.

Daniel

2009/10/20 Duncan Sands <baldrick at free.fr>

> Hi Daniel,
>
>  It may not be the best way to do what I'm trying to do, but it's not
>> useless and bogus. Consider the following:
>>
>> %1 = alloca i32* ; %1 is of type i32**, dereferenced it becomes a type
>> i32* and
>>                         ; the size of that is sizeof(void *) bytes
>>
>
> it is useless because getTypeAllocSize will handle any type, including
> pointer types.  It is bogus because your code assumes that the LLVM
> bitcode is targeting your own machine, i.e. that sizeof(void*) as given
> by your machine is correct for the target.  This may or may not be the
> case, but it is something best avoided.
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/06609793/attachment.html 

From jay.foad at gmail.com  Tue Oct 20 07:49:09 2009
From: jay.foad at gmail.com (Jay Foad)
Date: Tue, 20 Oct 2009 13:49:09 +0100
Subject: [LLVMdev] [cfe-dev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <ee2e06e90910200549m5cf70680ya8e2f80ba0efce87@mail.gmail.com>

> To test clang:
> 1) Compile llvm and clang from source.

LLVM fails to build for me on Cygwin. I get:

make[1]: Entering directory `/home/foad/llvm/objdir-2.6/runtime'
make[2]: Entering directory `/home/foad/llvm/objdir-2.6/runtime/libprofile'
llvm[2]: Compiling BasicBlockTracing.c for Release build (PIC)
llvm[2]: Compiling BlockProfiling.c for Release build (PIC)
llvm[2]: Compiling CommonProfiling.c for Release build (PIC)
llvm[2]: Compiling EdgeProfiling.c for Release build (PIC)
llvm[2]: Compiling FunctionProfiling.c for Release build (PIC)
llvm[2]: Linking Release Loadable Module profile_rt.dll
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
warning: cannot find entry symbol __cygwin_dll_entry at 12; defaulting to
61ec1000
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/BasicBlockTracing.o:BasicBlockTracing.c:(.text+0x36):
undefined reference to `_free'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/BasicBlockTracing.o:BasicBlockTracing.c:(.text+0xca):
undefined reference to `_malloc'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/BasicBlockTracing.o:BasicBlockTracing.c:(.text+0xe8):
undefined reference to `_atexit'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/BlockProfiling.o:BlockProfiling.c:(.text+0x65):
undefined reference to `_atexit'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x76):
undefined reference to `_strdup'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x9a):
undefined reference to `_memmove'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0xe3):
undefined reference to `_memmove'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x105):
undefined reference to `_printf'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x113):
undefined reference to `_puts'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x13c):
undefined reference to `_strlen'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x14e):
undefined reference to `_malloc'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x182):
undefined reference to `_strlen'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x19b):
undefined reference to `_memcpy'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x1fb):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x21a):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x23b):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x25e):
undefined reference to `_open'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x296):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x2b5):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x2d6):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x30d):
undefined reference to `_write'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x332):
undefined reference to `_fprintf'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/CommonProfiling.o:CommonProfiling.c:(.text+0x33e):
undefined reference to `_perror'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/EdgeProfiling.o:EdgeProfiling.c:(.text+0x65):
undefined reference to `_atexit'
/home/foad/llvm/objdir-2.6/runtime/libprofile/Release/FunctionProfiling.o:FunctionProfiling.c:(.text+0x65):
undefined reference to `_atexit'
collect2: ld returned 1 exit status
make[2]: *** [/home/foad/llvm/objdir-2.6/Release/lib/profile_rt.dll] Error 1
make[2]: Leaving directory `/home/foad/llvm/objdir-2.6/runtime/libprofile'
make[1]: *** [libprofile/.makeall] Error 2
make[1]: Leaving directory `/home/foad/llvm/objdir-2.6/runtime'
make: *** [all] Error 1

> When reporting your results, please provide details on what platform you compiled on, and how
> you built LLVM (src == obj, or src != obj), clang, and/or llvm-gcc.

$ uname -a
CYGWIN_NT-5.1 foad-pc 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin

src != obj

clang

Thanks,
Jay.

From kennethuil at gmail.com  Tue Oct 20 08:01:43 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 20 Oct 2009 08:01:43 -0500
Subject: [LLVMdev] Who is physically near Austin?
In-Reply-To: <85dfcd7f0910191004y748a5b40le98641e49f15e7a5@mail.gmail.com>
References: <400d33ea0910190840u711d3c2ajf023480fab9205a1@mail.gmail.com>
	<85dfcd7f0910191004y748a5b40le98641e49f15e7a5@mail.gmail.com>
Message-ID: <400d33ea0910200601r67247bd7v36d4e73ea9896ce1@mail.gmail.com>

OK, I'll assume for the moment that we're starting small.  Unless we
get a lot more people, I propose we just meet at 12:00 PM on Friday,
10/30/2009, at Bombay Bistro (183 & Braker).

If we do get a lot more people, I'll call ahead and see what I can set up.

From baldrick at free.fr  Tue Oct 20 08:02:12 2009
From: baldrick at free.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 15:02:12 +0200
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <4ADDB4D4.5010504@free.fr>

Hi Tanya,

> 1) Compile llvm from source and untar the llvm-test in the projects 
> directory (name it llvm-test or test-suite). Choose to use a 
> pre-compiled llvm-gcc or re-compile it yourself.

I compiled llvm and llvm-gcc with separate objects directories.
Platform is x86_64-linux-gnu.

> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
> that you need to reconfigure llvm with llvm-gcc in your path or with 
> --with-llvmgccdir

One failure:

FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
Failed with exit(1) at line 1
while running:  llvm-as < llvm-2.6/llvm-2.6/test/Feature/load_module.ll 
|  opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/LLVMHello.so -hello 
-disable-output - |& /bin/grep Hello
Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so': 
llvm-2.6-objects/Release/lib/LLVMHello.so: undefined symbol: _ZN4llvm4cerrE
child process exited abnormally

One unexpected pass:

XPASS: 
llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c

> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

Attached.

Ciao,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/20c8f18b/attachment-0001.txt 

From zhu.heyu at gmail.com  Tue Oct 20 08:59:58 2009
From: zhu.heyu at gmail.com (Heyu Zhu)
Date: Tue, 20 Oct 2009 21:59:58 +0800
Subject: [LLVMdev] Problem when build LLVM
In-Reply-To: <4ADD945B.9000209@free.fr>
References: <f41e75510910192244q70d5804cqaa3cf414ecb8b880@mail.gmail.com>
	<4ADD678D.9090209@free.fr>
	<f41e75510910200233v5fa7d8fbpc16638facf520463@mail.gmail.com>
	<4ADD945B.9000209@free.fr>
Message-ID: <f41e75510910200659p5169aca4n80af90f583a1b70f@mail.gmail.com>

Thanks to  Duncan and ?scar Fuentes.  With your help i have known the
reason.

I do install another software/tool  in tools/IUS611/tools/lib and
unfortunately
the tool's lirary file has the same name with gcc/g++'s, so error occurs.

After i modify LD_LIBRARY_PATH, i build the llvm successfully






2009/10/20, Duncan Sands <baldrick at free.fr>:
>
> Hi Heyu Zhu,
>
> According to your description i should not use the system libstdc++ and i
>> need to
>> specify the OTHER compiler libstdc++. But i don't where the OTHER compiler
>> libstdc++ is.
>> Is the  OTHER compiler libstdc++ contained in llvm-2.5.tar.gz? if not
>> where can i get it?
>>
>
> this has nothing to do with llvm, you would have the same problem with
> any C++ code that uses the C++ standard library.  As far as I can see
> you have installed a second compiler under /tools/IUS611/tools/.  Try
> looking for libstdc++ in /tools/IUS611/tools/lib.
>
> Ciao,
>
> Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/1abcb2f1/attachment.html 

From eocallaghan at auroraux.org  Tue Oct 20 09:45:23 2009
From: eocallaghan at auroraux.org (Edward O'Callaghan)
Date: Tue, 20 Oct 2009 15:45:23 +0100
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <4ADDB4D4.5010504@free.fr>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<4ADDB4D4.5010504@free.fr>
Message-ID: <521640720910200745pde9cdcu143a2917431599af@mail.gmail.com>

G'Day Tanya,

Is it too late to bring in the following patches to fix some major
brokenness in the AuroraUX tool chain for 2.6?

http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?r1=83846&r2=83847&view=diff&pathrev=83847
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?r1=84415&r2=84416&view=diff&pathrev=84416

All should be completely non intrusive.

Thanks for your time,
Edward O'Callaghan.

2009/10/20 Duncan Sands <baldrick at free.fr>:
> Hi Tanya,
>
>> 1) Compile llvm from source and untar the llvm-test in the projects
>> directory (name it llvm-test or test-suite). Choose to use a pre-compiled
>> llvm-gcc or re-compile it yourself.
>
> I compiled llvm and llvm-gcc with separate objects directories.
> Platform is x86_64-linux-gnu.
>
>> 2) Run make check, report any failures (FAIL or unexpected pass). Note
>> that you need to reconfigure llvm with llvm-gcc in your path or with
>> --with-llvmgccdir
>
> One failure:
>
> FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
> Failed with exit(1) at line 1
> while running: ?llvm-as < llvm-2.6/llvm-2.6/test/Feature/load_module.ll |
> ?opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/LLVMHello.so -hello
> -disable-output - |& /bin/grep Hello
> Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so':
> llvm-2.6-objects/Release/lib/LLVMHello.so: undefined symbol: _ZN4llvm4cerrE
> child process exited abnormally
>
> One unexpected pass:
>
> XPASS:
> llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c
>
>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> Attached.
>
> Ciao,
>
> Duncan.
>
> Program ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> GCCAS ?Bytecode LLC compile LLC-BETA compile JIT codegen | GCC ? ? CBE
> LLC ? ? LLC-BETA JIT ? ? | GCC/CBE GCC/LLC GCC/LLC-BETA LLC/LLC-BETA
> MultiSource/Applications/Burg/burg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.4400 112068 ? 0.9899 ? ? ?* ? ? ? ? ? ? ? ?1.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 1.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Applications/ClamAV/clamscan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 4.7699 1321972 ?8.1600 ? ? ?* ? ? ? ? ? ? ? ?4.5900 ? ? ?| ? ?0.37 *
> ?0.21 * ? ? ? ? ? 4.98 | n/a ? ? 1.76 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/JM/ldecod/ldecod ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 2.6799 664468 ? 3.1200 ? ? ?* ? ? ? ? ? ? ? ?2.5700 ? ? ?| ? ?0.12 ? ?0.11
> ?0.12 * ? ? ? ? ? 2.82 | 1.09 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/JM/lencod/lencod ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 5.6600 1462632 ?7.7899 ? ? ?* ? ? ? ? ? ? ? ?6.5999 ? ? ?| ? ?9.73 ? ?9.01
> ?8.99 * ? ? ? ? ?16.29 | 1.08 ? ?1.08 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/SIBsim4/SIBsim4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.4700 88500 ? ?0.5400 ? ? ?* ? ? ? ? ? ? ? ?0.5399 ? ? ?| ? ?4.91 *
> ?4.55 * ? ? ? ? ? 5.41 | n/a ? ? 1.08 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/SPASS/SPASS ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 6.5800 1603628 ?6.6600 ? ? ?* ? ? ? ? ? ? ? ?4.6100 ? ? ?| ? 10.54 ? 10.00
> ?9.98 * ? ? ? ? ?15.63 | 1.05 ? ?1.06 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/aha/aha ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0499 7356 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?3.23 ? ?2.97
> ?2.78 * ? ? ? ? ? 3.26 | 1.09 ? ?1.16 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/d/make_dparser ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 1.1100 311092 ? 1.1700 ? ? ?* ? ? ? ? ? ? ? ?1.0100 ? ? ?| ? ?0.03 *
> ?0.03 * ? ? ? ? ? 1.14 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Applications/hbd/hbd ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2500 82224 ? ?0.3999 ? ? ?* ? ? ? ? ? ? ? ?0.3400 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.39 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Applications/hexxagon/hexxagon ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2000 49988 ? ?0.2600 ? ? ?* ? ? ? ? ? ? ? ?0.2399 ? ? ?| ? 12.80 ? ?9.91
> ?9.62 * ? ? ? ? ? 9.42 | 1.29 ? ?1.33 ? ?n/a ? ? ? ? ?n/a
> ? ? ? ? ? ? ? ? ? ? ? ?llc:
> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/CBackend.cpp:488:
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&,
> const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 &&
> "Bit widths > 128 not implemented yet"' failed.
> MultiSource/Applications/kimwitu++/kc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 5.7400 1722276 ?8.1900 ? ? ?* ? ? ? ? ? ? ? ?5.5100 ? ? ?| ? ?0.18 *
> ?0.14 * ? ? ? ? ? 6.17 | n/a ? ? 1.29 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/lambda-0.1.3/lambda ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2100 66708 ? ?0.4300 ? ? ?* ? ? ? ? ? ? ? ?0.3199 ? ? ?| ? ?5.30 ? ?5.31
> ?5.36 * ? ? ? ? ? 6.34 | 1.00 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/lemon/lemon ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.4200 108608 ? 0.6300 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.07 ? ?0.07
> ?0.06 * ? ? ? ? 133.28 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Applications/lua/lua ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 1.7100 547448 ? 2.8600 ? ? ?* ? ? ? ? ? ? ? ?2.0899 ? ? ?| ? 27.89 *
> 27.87 * ? ? ? ? ?30.62 | n/a ? ? 1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/minisat/minisat ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2800 47664 ? ?0.2700 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?8.31 *
> ?8.28 * ? ? ? ?* ? ? ? | n/a ? ? 1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/obsequi/Obsequi ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.3600 61068 ? ?0.3499 ? ? ?* ? ? ? ? ? ? ? ?0.3200 ? ? ?| ? ?2.55 *
> ?2.48 * ? ? ? ? ? 3.00 | n/a ? ? 1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/oggenc/oggenc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 1.5600 815432 ? 1.3699 ? ? ?* ? ? ? ? ? ? ? ?1.1900 ? ? ?| ? ?0.19 *
> ?0.18 * ? ? ? ? ? 1.50 | n/a ? ? 1.06 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/sgefa/sgefa ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1200 17048 ? ?0.1099 ? ? ?* ? ? ? ? ? ? ? ?0.1199 ? ? ?| ? ?0.84 ? ?0.85
> ?0.84 * ? ? ? ? ? 1.00 | 0.99 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/siod/siod ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.7600 344780 ? 2.4000 ? ? ?* ? ? ? ? ? ? ? ?0.9599 ? ? ?| ? ?3.46 ? ?3.25
> ?3.42 * ? ? ? ? ? 4.62 | 1.06 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/spiff/spiff ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2000 51480 ? ?0.3100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.94 ? ?0.93
> ?0.96 * ? ? ? ?* ? ? ? | 1.01 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/sqlite3/sqlite3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 3.6800 1139780 ?6.3700 ? ? ?* ? ? ? ? ? ? ? ?4.6300 ? ? ?| ? ?5.10 *
> ?5.15 * ? ? ? ? ?10.40 | n/a ? ? 0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Applications/treecc/treecc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.7200 287712 ? 1.5700 ? ? ?* ? ? ? ? ? ? ? ?0.4299 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.47 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Applications/viterbi/viterbi ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0499 5460 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? 11.62 ? 11.68
> 11.81 * ? ? ? ? ?11.87 | 0.99 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/ASCI_Purple/SMG2000/smg2000 ? ? ? ? ? ? ? ? ? ? ? |
> 2.9899 498940 ? 3.0500 ? ? ?* ? ? ? ? ? ? ? ?2.2999 ? ? ?| ? ?4.51 ? ?4.23
> ?4.44 * ? ? ? ? ? 6.71 | 1.07 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0999 14168 ? ?0.0800 ? ? ?* ? ? ? ? ? ? ? ?0.0799 ? ? ?| ? 15.60 ? 15.84
> 15.72 * ? ? ? ? ?15.78 | 0.98 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/CrystalMk ? ? ? ? ? ? ? ? ? |
> 0.0500 8296 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?8.83 ? ?8.73
> ?8.69 * ? ? ? ? ? 8.77 | 1.01 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/ASC_Sequoia/IRSmk/IRSmk ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 5600 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/BitBench/drop3/drop3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 3592 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.48 ? ?0.66
> ?0.46 * ? ? ? ? ? 0.49 | 0.73 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/BitBench/five11/five11 ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 2768 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.33 ? ?2.44
> ?2.27 * ? ? ? ? ? 2.39 | 0.95 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/BitBench/uudecode/uudecode ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2968 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.13 ? ?0.12
> ?0.14 * ? ? ? ? ? 0.14 | 1.08 ? ?0.93 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/BitBench/uuencode/uuencode ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2764 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Fhourstones-3.1/fhourstones3.1 ? ? ? ? ? ? ? ? ? ?|
> 0.0500 8160 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?1.63 ? ?1.70
> ?1.58 * ? ? ? ? ? 1.64 | 0.96 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Fhourstones/fhourstones ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0699 11088 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?1.42 ? ?1.32
> ?1.33 * ? ? ? ? ? 1.39 | 1.08 ? ?1.07 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/analyzer/analyzer ? ? ? ? ? ? ? ? ? ? ? |
> 0.0600 10052 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.14 ? ?0.14
> ?0.12 * ? ? ? ? ? 0.18 | 1.00 ? ?1.17 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/distray/distray ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 6952 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.16 ? ?0.17
> ?0.18 * ? ? ? ? ? 0.23 | 0.94 ? ?0.89 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow ? ? ? ? ? ? ? ? ? |
> 0.1099 18888 ? ?0.1199 ? ? ?* ? ? ? ? ? ? ? ?0.0900 ? ? ?| ? ?0.36 ? ?0.35
> ?0.37 * ? ? ? ? ? 0.47 | 1.03 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/mason/mason ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 6148 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.23 ? ?0.26
> ?0.25 * ? ? ? ? ? 0.29 | 0.88 ? ?0.92 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/neural/neural ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0700 9712 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?0.24 ? ?0.27
> ?0.23 * ? ? ? ? ? 0.34 | 0.89 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 ? ? ? ? ? ? ? ? ? |
> 0.0599 11084 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.23 ? ?0.21
> ?0.21 * ? ? ? ? ? 0.29 | 1.10 ? ?1.10 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/FreeBench/pifft/pifft ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2900 60776 ? ?0.3400 ? ? ?* ? ? ? ? ? ? ? ?0.3300 ? ? ?| ? ?0.14 ? ?0.14
> ?0.14 * ? ? ? ? ? 0.50 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MallocBench/cfrac/cfrac ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2100 92260 ? ?0.3600 ? ? ?* ? ? ? ? ? ? ? ?0.3500 ? ? ?| ? ?1.44 ? ?1.44
> ?1.38 * ? ? ? ? ? 1.80 | 1.00 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MallocBench/espresso/espresso ? ? ? ? ? ? ? ? ? ? |
> 1.4700 414748 ? 2.4299 ? ? ?* ? ? ? ? ? ? ? ?1.6400 ? ? ?| ? ?0.61 ? ?0.55
> ?0.54 * ? ? ? ? ? 2.27 | 1.11 ? ?1.13 ? ?n/a ? ? ? ? ?n/a
> ? ? ? ? ? ? ? ? ? ? ? ?llc:
> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/CBackend.cpp:488:
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&,
> const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 &&
> "Bit widths > 128 not implemented yet"' failed.
> MultiSource/Benchmarks/MallocBench/gs/gs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 1.2000 376224 ? 1.7600 ? ? ?* ? ? ? ? ? ? ? ?0.7900 ? ? ?| ? ?0.07 *
> ?0.06 * ? ? ? ? ? 0.95 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/01-qbsort/qbsort ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0099 3600 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.07 ? ?0.06
> ?0.05 * ? ? ? ? ? 0.10 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/03-testtrie/testtrie ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 3756 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.02 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/04-bisect/bisect ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 4036 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?0.14 ? ?0.13
> ?0.13 * ? ? ? ? ? 0.17 | 1.08 ? ?1.08 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/05-eks/eks ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0999 7888 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.01 ? ?0.00
> ?0.02 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/08-main/main ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0900 11928 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0599 ? ? ?| ? ?0.07 ? ?0.03
> ?0.03 * ? ? ? ? ? 0.09 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/09-vor/vor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0999 23148 ? ?0.1300 ? ? ?* ? ? ? ? ? ? ? ?0.1200 ? ? ?| ? ?0.15 ? ?0.12
> ?0.11 * ? ? ? ? ? 0.25 | 1.25 ? ?1.36 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/12-IOtest/iotest ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0199 2176 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.33 ? ?0.23
> ?0.20 * ? ? ? ? ? 0.23 | 1.43 ? ?1.65 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/15-trie/trie ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 3216 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/17-bintr/bintr ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0199 3676 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.11 ? ?0.10
> ?0.11 * ? ? ? ? ? 0.13 | 1.10 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/McCat/18-imp/imp ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0999 21512 ? ?0.1099 ? ? ?* ? ? ? ? ? ? ? ?0.1200 ? ? ?| ? ?0.07 *
> ?0.08 * ? ? ? ? ? 0.20 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> ? ? ? ? ? ? ? ? ? ? ? ?llc:
> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/CBackend.cpp:488:
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&,
> const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 &&
> "Bit widths > 128 not implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive-basicmath |
> 0.0200 4816 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.40 ? ?0.39
> ?0.39 * ? ? ? ? ? 0.44 | 1.03 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive-bitcount ? |
> 0.0300 3540 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0399 ? ? ?| ? ?0.13 ? ?0.13
> ?0.15 * ? ? ? ? ? 0.19 | 1.00 ? ?0.87 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/automotive-susan/automotive-susan ? ? ? ? |
> 0.2500 64756 ? ?0.3100 ? ? ?* ? ? ? ? ? ? ? ?0.3200 ? ? ?| ? ?0.07 ? ?0.06
> ?0.05 * ? ? ? ? ? 0.38 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer-jpeg ? ? ? ? ? ? ? |
> 1.2500 205708 ? 0.9300 ? ? ?* ? ? ? ? ? ? ? ?0.4900 ? ? ?| ? ?0.02 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.54 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> ? ? ? ? ? ? ? ? ? ? ? ?llc:
> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/CBackend.cpp:488:
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType(llvm::formatted_raw_ostream&,
> const llvm::Type*, bool, const std::string&): Assertion `NumBits <= 128 &&
> "Bit widths > 128 not implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame ? ? ? ? ? ? ? |
> 1.3200 335108 ? 1.3200 ? ? ?* ? ? ? ? ? ? ? ?1.2100 ? ? ?| ? ?0.28 *
> ?0.27 * ? ? ? ? ? 1.58 | n/a ? ? 1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer-typeset ? ? ? ? |
> 5.7999 1397316 ?6.9899 ? ? ?* ? ? ? ? ? ? ? ?6.0300 ? ? ?| ? ?0.35 *
> ?0.22 * ? ? ? ? ? 6.47 | n/a ? ? 1.59 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/network-dijkstra/network-dijkstra ? ? ? ? |
> 0.0100 3512 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.04 ? ?0.05
> ?0.05 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/network-patricia/network-patricia ? ? ? ? |
> 0.0300 4248 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.14 ? ?0.12
> ?0.12 * ? ? ? ? ? 0.16 | 1.17 ? ?1.17 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/office-ispell/office-ispell ? ? ? ? ? ? ? |
> 0.5400 128620 ? 0.7899 ? ? ?* ? ? ? ? ? ? ? ?0.2400 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.26 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/office-stringsearch/office-stringsearch ? |
> 0.0200 13232 ? ?0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/security-blowfish/security-blowfish ? ? ? |
> 0.0999 30936 ? ?0.1099 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael ? ? ? |
> 0.1400 51232 ? ?0.1000 ? ? ?* ? ? ? ? ? ? ? ?0.0700 ? ? ?| ? ?0.08 ? ?0.06
> ?0.07 * ? ? ? ? ? 0.16 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/security-sha/security-sha ? ? ? ? ? ? ? ? |
> 0.0300 4760 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.07 ? ?0.03
> ?0.03 * ? ? ? ? ? 0.05 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm-CRC32 ? ? ? ? ? ? |
> 0.0000 3180 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.41 ? ?0.28
> ?0.28 * ? ? ? ? ? 0.30 | 1.46 ? ?1.46 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm-fft ? ? ? ? ? ? ? ? |
> 0.0200 4880 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?0.06 ? ?0.07
> ?0.06 * ? ? ? ? ? 0.09 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/telecomm-adpcm/telecomm-adpcm ? ? ? ? ? ? |
> 0.0000 2196 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm-gsm ? ? ? ? ? ? ? ? |
> 0.3500 76716 ? ?0.3299 ? ? ?* ? ? ? ? ? ? ? ?0.1900 ? ? ?| ? ?0.23 ? ?0.24
> ?0.23 * ? ? ? ? ? 0.43 | 0.96 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/NPB-serial/is/is ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0099 5116 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.3599 ? ? ?| ? 10.08 ? ?9.85
> ?9.84 * ? ? ? ? ?10.18 | 1.02 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/bh/bh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1199 15308 ? ?0.0800 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?1.97 *
> ?1.57 * ? ? ? ? ? 1.67 | n/a ? ? 1.25 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/bisort/bisort ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 3688 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.80 ? ?0.82
> ?0.79 * ? ? ? ? ? 0.81 | 0.98 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/em3d/em3d ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0400 6412 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?3.30 ? ?3.29
> ?3.29 * ? ? ? ? ? 3.32 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/health/health ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 7608 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.52 *
> ?0.50 * ? ? ? ? ? 0.54 | n/a ? ? 1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/mst/mst ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0500 4176 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.15 ? ?0.14
> ?0.14 * ? ? ? ? ? 0.18 | 1.07 ? ?1.07 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/perimeter/perimeter ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 12340 ? ?0.0799 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?0.36 ? ?0.34
> ?0.32 * ? ? ? ? ? 0.38 | 1.06 ? ?1.12 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/power/power ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 8564 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.56 ? ?1.55
> ?1.52 * ? ? ? ? ? 1.57 | 1.01 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/treeadd/treeadd ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1824 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.33 ? ?0.34
> ?0.34 * ? ? ? ? ? 0.34 | 0.97 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/tsp/tsp ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 6988 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?1.15 ? ?1.13
> ?1.14 * ? ? ? ? ? 1.16 | 1.02 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Olden/voronoi/voronoi ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0900 13436 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.42 ? ?0.41
> ?0.42 * ? ? ? ? ? 0.48 | 1.02 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/OptimizerEval/optimizer-eval ? ? ? ? ? ? ? ? ? ? ?|
> 0.0800 29224 ? ?0.1500 ? ? ?* ? ? ? ? ? ? ? ?0.1800 ? ? ?| ?106.85 ?110.58
> ?109.30 * ? ? ? ? ?96.14 | 0.97 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/PAQ8p/paq8p ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.9300 198188 ? 1.0400 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.01 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/NP/np ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1188 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/city/city ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1199 23708 ? ?0.0800 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?0.01 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.09 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1 ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0600 12928 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2 ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 14480 ? ?0.0700 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/employ/employ ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1000 21900 ? ?0.1099 ? ? ?* ? ? ? ? ? ? ? ?0.0799 ? ? ?| ? ?0.02 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.10 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/family/family ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 3388 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/fsm/fsm ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1904 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/garage/garage ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0499 7428 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/life/life ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 6324 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.38 ? ?1.44
> ?1.45 * ? ? ? ? ? 1.48 | 0.96 ? ?0.95 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/objects/objects ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 9980 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/ocean/ocean ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 8880 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0399 ? ? ?| ? ?0.12 ? ?0.11
> ?0.12 * ? ? ? ? ? 0.16 | 1.09 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/office/office ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 12924 ? ?0.0699 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/primes/primes ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1584 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.37 ? ?0.35
> ?0.35 * ? ? ? ? ? 0.37 | 1.06 ? ?1.06 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/shapes/shapes ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0399 16268 ? ?0.0899 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?0.01 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.08 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/simul/simul ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0600 4176 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/trees/trees ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0500 11288 ? ?0.0700 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C++/vcirc/vcirc ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1768 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/timberwolfmc ? ? ? ? ? ? ?|
> 1.7300 563480 ? 3.2999 ? ? ?* ? ? ? ? ? ? ? ?0.5900 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.63 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/agrep/agrep ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.3700 92964 ? ?0.5300 ? ? ?* ? ? ? ? ? ? ? ?0.1999 ? ? ?| ? ?0.02 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.23 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/allroots/allroots ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 3556 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/archie-client/archie ? ? ? ? ? ? ? ? ? |
> 0.2000 47648 ? ?0.2199 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.01 *
> ?0.00 * ? ? ? ? ? 0.07 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/assembler/assembler ? ? ? ? ? ? ? ? ? ?|
> 0.1600 61544 ? ?0.3900 ? ? ?* ? ? ? ? ? ? ? ?0.2999 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.33 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/bison/mybison ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.3600 112424 ? 0.9900 ? ? ?* ? ? ? ? ? ? ? ?0.9100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.95 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/cdecl/cdecl ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0999 48484 ? ?0.3199 ? ? ?* ? ? ? ? ? ? ? ?0.3400 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.35 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/compiler/compiler ? ? ? ? ? ? ? ? ? ? ?|
> 0.1100 36440 ? ?0.2900 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/fixoutput/fixoutput ? ? ? ? ? ? ? ? ? ?|
> 0.0100 6044 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/football/football ? ? ? ? ? ? ? ? ? ? ?|
> 0.3500 85712 ? ?0.5500 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.05 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/gnugo/gnugo ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1400 35692 ? ?0.2100 ? ? ?* ? ? ? ? ? ? ? ?0.2200 ? ? ?| ? ?0.07 ? ?0.07
> ?0.07 * ? ? ? ? ? 0.30 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/loader/loader ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0899 28276 ? ?0.1400 ? ? ?* ? ? ? ? ? ? ? ?0.1199 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.14 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/plot2fig/plot2fig ? ? ? ? ? ? ? ? ? ? ?|
> 0.0500 14756 ? ?0.0900 ? ? ?* ? ? ? ? ? ? ? ?0.0999 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.11 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/simulator/simulator ? ? ? ? ? ? ? ? ? ?|
> 0.2600 64712 ? ?0.4000 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/unix-smail/unix-smail ? ? ? ? ? ? ? ? ?|
> 0.1100 39652 ? ?0.3000 ? ? ?* ? ? ? ? ? ? ? ?0.2000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.22 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Prolangs-C/unix-tbl/unix-tbl ? ? ? ? ? ? ? ? ? ? ?|
> 0.3000 78708 ? ?0.4900 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Ptrdist/anagram/anagram ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0500 7764 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.46 ? ?0.97
> ?1.38 * ? ? ? ? ? 1.36 | 1.51 ? ?1.06 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Ptrdist/bc/bc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.3300 126012 ? 0.7700 ? ? ?* ? ? ? ? ? ? ? ?0.7100 ? ? ?| ? ?0.66 ? ?0.68
> ?0.64 * ? ? ? ? ? 1.41 | 0.97 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Ptrdist/ft/ft ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0600 7236 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?1.17 ? ?1.22
> ?1.27 * ? ? ? ? ? 1.28 | 0.96 ? ?0.92 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Ptrdist/ks/ks ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0299 11912 ? ?0.0699 ? ? ?* ? ? ? ? ? ? ? ?0.0700 ? ? ?| ? ?2.23 ? ?1.44
> ?2.26 * ? ? ? ? ? 2.21 | 1.55 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Ptrdist/yacr2/yacr2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.2200 48228 ? ?0.3600 ? ? ?* ? ? ? ? ? ? ? ?0.3100 ? ? ?| ? ?1.23 ? ?1.10
> ?1.22 * ? ? ? ? ? 1.56 | 1.12 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/SciMark2-C/scimark2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1099 15340 ? ?0.0799 ? ? ?* ? ? ? ? ? ? ? ?0.0999 ? ? ?| ? 27.62 *
> 27.38 * ? ? ? ? ?27.87 | n/a ? ? 1.01 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/enc-3des/enc-3des ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1599 21456 ? ?0.1000 ? ? ?* ? ? ? ? ? ? ? ?0.1200 ? ? ?| ? ?2.23 ? ?2.10
> ?2.14 * ? ? ? ? ? 2.31 | 1.06 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/enc-md5/enc-md5 ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0599 7692 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?2.16 ? ?2.04
> ?2.05 * ? ? ? ? ? 2.21 | 1.06 ? ?1.05 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/enc-pc1/enc-pc1 ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 3964 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.39 ? ?0.97
> ?0.92 * ? ? ? ? ? 0.95 | 1.43 ? ?1.51 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/enc-rc4/enc-rc4 ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 2960 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.18 ? ?1.20
> ?1.16 * ? ? ? ? ? 1.24 | 0.98 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/netbench-crc/netbench-crc ? ? ? ? ? ? ? ?|
> 0.0000 32680 ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.01 ? ?1.00
> ?1.09 * ? ? ? ? ? 1.07 | 1.01 ? ?0.93 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/Trimaran/netbench-url/netbench-url ? ? ? ? ? ? ? ?|
> 0.0400 40832 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?3.89 ? ?3.45
> ?3.88 * ? ? ? ? ? 3.94 | 1.13 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/VersaBench/8b10b/8b10b ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 2240 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?7.07 ? ?4.94
> ?4.99 * ? ? ? ? ? 4.97 | 1.43 ? ?1.42 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/VersaBench/beamformer/beamformer ? ? ? ? ? ? ? ? ?|
> 0.0400 5764 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.85 ? ?1.92
> ?1.76 * ? ? ? ? ? 1.80 | 0.96 ? ?1.05 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/VersaBench/bmm/bmm ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0199 2896 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?2.34 ? ?2.35
> ?2.36 * ? ? ? ? ? 2.39 | 1.00 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/VersaBench/dbms/dbms ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1200 36468 ? ?0.2500 ? ? ?* ? ? ? ? ? ? ? ?0.2400 ? ? ?| ? ?2.34 ? ?2.23
> ?2.17 * ? ? ? ? ? 2.35 | 1.05 ? ?1.08 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0599 9740 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?2.87 ? ?2.91
> ?2.77 * ? ? ? ? ? 2.76 | 0.99 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/llubenchmark/llu ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 3896 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?6.10 ? ?6.30
> ?6.24 * ? ? ? ? ? 6.31 | 0.97 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mafft/pairlocalalign ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 3.7200 346176 ? 1.9100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawcaudio/rawcaudio ? ? ? ? ? ? ?|
> 0.0100 2324 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/rawdaudio ? ? ? ? ? ? ?|
> 0.0100 2196 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/g721/g721encode/encode ? ? ? ? ? ? ? ? |
> 0.0600 13104 ? ?0.0800 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.09 ? ?0.09
> ?0.08 * ? ? ? ? ? 0.14 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/gsm/toast/toast ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.3800 76716 ? ?0.2700 ? ? ?* ? ? ? ? ? ? ? ?0.2099 ? ? ?| ? ?0.06 ? ?0.04
> ?0.03 * ? ? ? ? ? 0.24 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/cjpeg ? ? ? ? ? ? ? ? ? ? |
> 1.2000 172872 ? 0.7500 ? ? ?* ? ? ? ? ? ? ? ?0.5500 ? ? ?| ? ?0.02 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.61 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/mpeg2decode ? ? ? ? ? ? |
> 0.4500 101376 ? 0.5500 ? ? ?* ? ? ? ? ? ? ? ?0.5400 ? ? ?| ? ?0.04 ? ?0.02
> ?0.03 * ? ? ? ? ? 0.58 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/sim/sim ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0699 28828 ? ?0.1800 ? ? ?* ? ? ? ? ? ? ? ?0.1800 ? ? ?| ? ?5.21 ? ?5.51
> ?5.24 * ? ? ? ? ? 5.82 | 0.95 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 9.2000 1943356 ?5.4000 ? ? ?* ? ? ? ? ? ? ? ?5.1900 ? ? ?| ? ?0.76 *
> ?0.64 * ? ? ? ? ? 6.36 | n/a ? ? 1.19 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/functionobjects ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.2100 37048 ? ?0.1799 ? ? ?* ? ? ? ? ? ? ? ?0.1500 ? ? ?| ? ?3.97 ? ?3.53
> ?3.43 * ? ? ? ? ? 3.66 | 1.12 ? ?1.16 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/loop_unroll ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 1.0500 328448 ? 1.6400 ? ? ?* ? ? ? ? ? ? ? ?1.7599 ? ? ?| ? ?2.01 ? ?1.55
> ?1.81 * ? ? ? ? ? 3.63 | 1.30 ? ?1.11 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding ? ? ? ? ?|
> 0.8100 185728 ? 2.1699 ? ? ?* ? ? ? ? ? ? ? ?2.2599 ? ? ?| ? ?1.29 ? ?1.29
> ?1.24 * ? ? ? ? ? 3.61 | 1.00 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant ? ? ? ? ? ?|
> 0.6200 137560 ? 1.1100 ? ? ?* ? ? ? ? ? ? ? ?1.1199 ? ? ?| ? ?3.01 ? ?3.02
> ?2.97 * ? ? ? ? ? 4.15 | 1.00 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/stepanov_abstraction ? ? ? ? ? ? ? ? ? |
> 0.2900 37900 ? ?0.1700 ? ? ?* ? ? ? ? ? ? ? ?0.1599 ? ? ?| ? ?5.00 ? ?5.44
> ?5.26 * ? ? ? ? ? 5.55 | 0.92 ? ?0.95 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Adobe-C++/stepanov_vector ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.2800 41564 ? ?0.1999 ? ? ?* ? ? ? ? ? ? ? ?0.2100 ? ? ?| ? ?2.93 ? ?3.09
> ?2.97 * ? ? ? ? ? 3.19 | 0.95 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/fannkuch ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0199 2840 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?3.45 ? ?4.30
> ?3.49 * ? ? ? ? ? 3.57 | 0.80 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/fasta ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 3000 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?1.17 ? ?1.19
> ?1.16 * ? ? ? ? ? 1.18 | 0.98 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/n-body ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 3176 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.20 ? ?1.19
> ?1.24 * ? ? ? ? ? 1.23 | 1.01 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/nsieve-bits ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1120 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.99 ? ?1.02
> ?1.00 * ? ? ? ? ? 0.96 | 0.97 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/partialsums ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1660 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.85 ? ?0.91
> ?0.90 * ? ? ? ? ? 0.83 | 0.93 ? ?0.94 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/puzzle ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 1276 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.54 ? ?0.54
> ?0.54 * ? ? ? ? ? 0.54 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/recursive ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 3444 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?1.21 ? ?0.86
> ?0.94 * ? ? ? ? ? 1.14 | 1.41 ? ?1.29 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/BenchmarkGame/spectral-norm ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 2808 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?1.37 ? ?1.41
> ?1.41 * ? ? ? ? ? 1.41 | 0.97 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/CoyoteBench/almabench ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 5776 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? 16.77 ? ?7.95
> ?8.05 * ? ? ? ? ? 8.12 | 2.11 ? ?2.08 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/CoyoteBench/fftbench ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1400 22432 ? ?0.0900 ? ? ?* ? ? ? ? ? ? ? ?0.0999 ? ? ?| ? ?2.26 *
> ?2.21 * ? ? ? ? ? 2.35 | n/a ? ? 1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/CoyoteBench/huffbench ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 6584 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? 19.18 ? 17.21
> 18.83 * ? ? ? ? ?19.82 | 1.11 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/CoyoteBench/lpbench ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 4556 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? 10.94 ? 10.91
> 10.95 * ? ? ? ? ?10.94 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Dhrystone/dry ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1300 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?3.29 ? ?0.35
> ?0.62 * ? ? ? ? ? 0.59 | 9.40 ? ?5.31 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Dhrystone/fldry ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0099 1308 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?3.66 ? ?0.46
> ?0.58 * ? ? ? ? ? 0.56 | 7.96 ? ?6.31 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/McGill/chomp ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0400 6596 ? ? 0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?1.36 ? ?1.03
> ?1.00 * ? ? ? ? ? 1.08 | 1.32 ? ?1.36 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/McGill/exptree ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 4936 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/McGill/misr ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2708 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.29 ? ?0.30
> ?0.28 * ? ? ? ? ? 0.31 | 0.97 ? ?1.04 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/McGill/queens ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0199 3348 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?2.39 ? ?2.40
> ?2.36 * ? ? ? ? ? 2.54 | 1.00 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/bigfib ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1900 40720 ? ?0.2000 ? ? ?* ? ? ? ? ? ? ? ?0.1700 ? ? ?| ? ?0.56 *
> ?0.56 * ? ? ? ? ? 0.77 | n/a ? ? 1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/mandel-text ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1016 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.26 ? ?2.26
> ?2.25 * ? ? ? ? ? 2.25 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/oopack_v1p8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0700 9528 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.17 ? ?0.18
> ?0.18 * ? ? ? ? ? 0.24 | 0.94 ? ?0.94 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/ray ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0800 17220 ? ?0.0700 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?4.25 ? ?4.09
> ?4.16 * ? ? ? ? ? 4.20 | 1.04 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/sphereflake ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0799 16776 ? ?0.0799 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?3.09 ? ?2.79
> ?2.85 * ? ? ? ? ? 2.98 | 1.11 ? ?1.08 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/stepanov_container ? ? ? ? ? ? ? ? ? ? ?|
> 0.2900 46332 ? ?0.1799 ? ? ?* ? ? ? ? ? ? ? ?0.1899 ? ? ?| ? ?4.29 ? ?4.40
> ?4.30 * ? ? ? ? ? 4.68 | 0.97 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc-C++/stepanov_v1p2 ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0800 10116 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?7.87 ? ?8.27
> ?8.11 * ? ? ? ? ? 8.24 | 0.95 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/ReedSolomon ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0799 10636 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?7.06 ? ?7.27
> ?7.06 * ? ? ? ? ? 7.49 | 0.97 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/fbench ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 5424 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?2.30 ? ?2.23
> ?2.29 * ? ? ? ? ? 2.34 | 1.03 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/ffbench ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 4828 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.04 ? ?1.00
> ?1.04 * ? ? ? ? ? 1.08 | 1.04 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 6552 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? 12.41 ? 12.50
> 12.63 * ? ? ? ? ?12.68 | 0.99 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1152 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.59 ? ?2.53
> ?2.54 * ? ? ? ? ? 2.53 | 1.02 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1252 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?1.46 ? ?1.46
> ?1.46 * ? ? ? ? ? 1.49 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1172 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.63 ? ?3.13
> ?2.97 * ? ? ? ? ? 2.98 | 0.84 ? ?0.89 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1152 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?1.23 ? ?1.37
> ?1.34 * ? ? ? ? ? 1.36 | 0.90 ? ?0.92 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-5 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1284 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?2.15 ? ?4.37
> ?4.34 * ? ? ? ? ? 4.35 | 0.49 ? ?0.50 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-6 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1284 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.23 ? ?4.94
> ?4.92 * ? ? ? ? ? 4.92 | 0.45 ? ?0.45 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-7 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1080 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?3.91 ? ?3.79
> ?3.79 * ? ? ? ? ? 4.74 | 1.03 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/flops-8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1288 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?2.23 ? ?2.43
> ?2.29 * ? ? ? ? ? 2.30 | 0.92 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/himenobmtxpa ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0600 9672 ? ? 0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?2.11 ? ?2.00
> ?1.99 * ? ? ? ? ? 2.10 | 1.05 ? ?1.06 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/mandel ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1080 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.05 ? ?1.02
> ?1.04 * ? ? ? ? ? 1.41 | 1.03 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/mandel-2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1052 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?1.01 ? ?1.10
> ?1.00 * ? ? ? ? ? 1.00 | 0.92 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/oourafft ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1100 13740 ? ?0.0700 ? ? ?* ? ? ? ? ? ? ? ?0.0699 ? ? ?| ? ?8.26 ? ?7.63
> ?7.81 * ? ? ? ? ? 6.87 | 1.08 ? ?1.06 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/perlin ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 4512 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?6.64 ? ?6.67
> ?6.65 * ? ? ? ? ? 6.89 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/pi ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1152 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.77 ? ?0.79
> ?0.76 * ? ? ? ? ? 0.84 | 0.97 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/richards_benchmark ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 5756 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?1.13 ? ?1.05
> ?1.17 * ? ? ? ? ? 1.33 | 1.08 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/salsa20 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 2692 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?9.30 ? ?9.72
> ?9.27 * ? ? ? ? ? 9.33 | 0.96 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Misc/whetstone ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0199 3344 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?1.63 ? ?1.52
> ?1.52 * ? ? ? ? ? 1.58 | 1.07 ? ?1.07 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/ackermann ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0499 11044 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?1.14 ? ?1.14
> ?1.14 * ? ? ? ? ? 1.39 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/ary ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 9120 ? ? 0.0299 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?0.12 ? ?0.11
> ?0.11 * ? ? ? ? ? 0.16 | 1.09 ? ?1.09 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/ary2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0599 9784 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.12 ? ?0.12
> ?0.12 * ? ? ? ? ? 0.17 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/ary3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0599 11616 ? ?0.0599 ? ? ?* ? ? ? ? ? ? ? ?0.0599 ? ? ?| ? ?4.28 ? ?4.26
> ?4.30 * ? ? ? ? ? 4.34 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/except ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0399 11292 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.42 *
> ?0.41 * ? ? ? ?* ? ? ? | n/a ? ? 1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/fibo ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 7836 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.50 ? ?0.57
> ?0.51 * ? ? ? ? ? 0.63 | 0.88 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/hash ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0700 15036 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.1300 ? ? ?| ? ?0.60 ? ?0.58
> ?0.59 * ? ? ? ? ? 0.78 | 1.03 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/hash2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1900 20104 ? ?0.1000 ? ? ?* ? ? ? ? ? ? ? ?0.0899 ? ? ?| ? ?4.53 ? ?4.35
> ?4.33 * ? ? ? ? ? 4.76 | 1.04 ? ?1.05 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/heapsort ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 3012 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?4.26 ? ?4.05
> ?4.15 * ? ? ? ? ? 4.25 | 1.05 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/hello ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 8304 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/lists ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0899 11392 ? ?0.0499 ? ? ?* ? ? ? ? ? ? ? ?0.0399 ? ? ?| ? ?5.90 ? ?6.00
> ?5.86 * ? ? ? ? ? 6.10 | 0.98 ? ?1.01 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/lists1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1200 16204 ? ?0.0799 ? ? ?* ? ? ? ? ? ? ? ?0.1199 ? ? ?| ? ?0.33 ? ?0.34
> ?0.33 * ? ? ? ? ? 0.46 | 0.97 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/matrix ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 12192 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0599 ? ? ?| ? ?3.33 ? ?3.34
> ?3.35 * ? ? ? ? ? 3.40 | 1.00 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/methcall ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0299 10800 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0299 ? ? ?| ? ?5.47 ? ?5.57
> ?5.59 * ? ? ? ? ? 8.15 | 0.98 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/moments ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0599 9084 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.18 ? ?0.20
> ?0.20 * ? ? ? ? ? 0.22 | 0.90 ? ?0.90 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/nestedloop ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0499 8064 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.18 ? ?0.01
> ?0.18 * ? ? ? ? ? 0.22 | - ? ? ? 1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/objinst ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0400 10992 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?5.73 ? ?5.80
> ?5.64 * ? ? ? ? ? 5.66 | 0.99 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/random ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0500 7816 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0299 ? ? ?| ? ?4.68 ? ?4.55
> ?4.69 * ? ? ? ? ? 4.59 | 1.03 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/reversefile ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.1500 17388 ? ?0.0600 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.00 *
> ?0.00 * ? ? ? ? ? 0.07 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/sieve ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0900 12556 ? ?0.0499 ? ? ?* ? ? ? ? ? ? ? ?0.0499 ? ? ?| ? ?2.35 ? ?2.50
> ?2.49 * ? ? ? ? ? 2.43 | 0.94 ? ?0.94 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/spellcheck ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1600 27772 ? ?0.1200 ? ? ?* ? ? ? ? ? ? ? ?0.0799 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.09 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/strcat ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0699 10564 ? ?0.0500 ? ? ?* ? ? ? ? ? ? ? ?0.0399 ? ? ?| ? ?0.15 *
> ?0.10 * ? ? ? ? ? 0.15 | n/a ? ? 1.50 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/sumcol ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0499 9016 ? ? 0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/wc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0599 11144 ? ?0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.05 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout-C++/wordfreq ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.1000 18728 ? ?0.0900 ? ? ?* ? ? ? ? ? ? ? ?0.0500 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/ackermann ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1192 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.02 ? ?0.01
> ?0.01 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/ary3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1148 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?4.40 ? ?4.32
> ?4.48 * ? ? ? ? ? 4.33 | 1.02 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/fib2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 964 ? ? ?0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.50 ? ?0.58
> ?0.51 * ? ? ? ? ? 0.60 | 0.86 ? ?0.98 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/hash ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0300 3028 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?3.79 ? ?3.80
> ?3.83 * ? ? ? ? ? 4.08 | 1.00 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/heapsort ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1452 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?4.10 ? ?4.09
> ?4.13 * ? ? ? ? ? 4.32 | 1.00 ? ?0.99 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/hello ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 576 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/lists ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 3144 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?5.85 ? ?5.77
> ?5.75 * ? ? ? ? ? 6.34 | 1.01 ? ?1.02 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/matrix ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0099 4128 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?3.88 ? ?3.88
> ?3.87 * ? ? ? ? ? 3.90 | 1.00 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/methcall ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1580 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0099 ? ? ?| ? ?4.52 ? ?4.41
> ?4.51 * ? ? ? ? ? 7.02 | 1.02 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/nestedloop ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 1128 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.18 ? ?0.02
> ?0.17 * ? ? ? ? ? 0.25 | - ? ? ? 1.06 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/objinst ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1676 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?5.01 ? ?5.50
> ?5.17 * ? ? ? ? ? 5.06 | 0.91 ? ?0.97 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/random ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 864 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?4.55 ? ?4.52
> ?4.53 * ? ? ? ? ? 4.54 | 1.01 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/sieve ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1288 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?6.56 ? ?5.95
> ?6.55 * ? ? ? ? ? 6.46 | 1.10 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Shootout/strcat ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1336 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.20 ? ?0.19
> ?0.20 * ? ? ? ? ? 0.22 | 1.05 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Bubblesort ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1420 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.05 ? ?0.06
> ?0.07 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/IntMM ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 1476 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Oscar ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 3148 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Perm ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 3124 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.04 ? ?0.04
> ?0.04 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Puzzle ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0999 4820 ? ? 0.0199 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.17 ? ?0.19
> ?0.18 * ? ? ? ? ? 0.20 | 0.89 ? ?0.94 ? ?n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Queens ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2232 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0199 ? ? ?| ? ?0.05 ? ?0.05
> ?0.04 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Quicksort ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1752 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.05 ? ?0.05
> ?0.06 * ? ? ? ? ? 0.07 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/RealMM ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1508 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Towers ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2440 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.04 ? ?0.04
> ?0.03 * ? ? ? ? ? 0.05 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Benchmarks/Stanford/Treesort ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 2248 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0200 ? ? ?| ? ?0.10 ? ?0.10
> ?0.08 * ? ? ? ? ? 0.11 | 1.00 ? ?- ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-05-14-array-init ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 584 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-05-14-expr_stmt ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 484 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-06-08-BaseType ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 496 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-06-08-VirtualFunctions ? ? ? ? ? ? ? ? ?|
> 0.0000 620 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-06-13-Crasher ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 456 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-08-20-EnumSizeProblem ? ? ? ? ? ? ? ? ? |
> 0.0000 456 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2003-09-29-NonPODsByValue ? ? ? ? ? ? ? ? ? ?|
> 0.0000 576 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/2008-01-29-ParamAliasesReturn ? ? ? ? ? ? ? ?|
> 0.0200 604 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/BuiltinTypeInfo ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 728 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/ConditionalExpr ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0099 712 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/ctor_dtor_count ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1056 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.00 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/ctor_dtor_count-2 ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1584 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.00 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/dead_try_block ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 568 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/exception_spec_test ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 2472 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.01 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/function_try_block ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 2460 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.00 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/simple_rethrow ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1452 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.01 *
> ?0.00 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/simple_throw ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 956 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.01 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/EH/throw_rethrow_test ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1792 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 *
> ?0.00 * ? ? ? ?* ? ? ? | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/global_ctor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1344 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/global_type ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 456 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/ofstream_ctor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 9176 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/pointer_member ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 660 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/pointer_method ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 664 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C++/short_circuit_dtor ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 644 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-14-initialize-string ? ? ? ? ? ? ? ? ? |
> 0.0000 680 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-21-BitfieldHandling ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1152 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 *
> ?0.00 * ? ? ? ? ? 0.00 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-21-UnionBitfields ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 580 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-21-UnionTest ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 580 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-22-LocalTypeTest ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 624 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-22-VarSizeArray ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 580 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-05-23-TransparentUnion ? ? ? ? ? ? ? ? ? ?|
> 0.0000 576 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-06-16-InvalidInitializer ? ? ? ? ? ? ? ? ?|
> 0.0000 456 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-06-16-VolatileError ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 456 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2003-10-12-GlobalVarInitializers ? ? ? ? ? ? ? |
> 0.0000 664 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2004-02-03-AggregateCopy ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 588 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2004-03-15-IndirectGoto ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 860 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2004-08-12-InlinerAndAllocas ? ? ? ? ? ? ? ? ? |
> 0.0000 828 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2005-05-06-LongLongSignedShift ? ? ? ? ? ? ? ? |
> 0.0000 608 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/2008-01-07-LongDouble ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 596 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/ConstructorDestructorAttributes ? ? ? ? ? ? ? ?|
> 0.0000 760 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/DuffsDevice ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1084 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/PR1386 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 588 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/PR491 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 456 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/PR640 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 2076 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/badidx ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1012 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/bigstack ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 4820 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/callargs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 928 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/casts ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 3612 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.03 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/globalrefs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 932 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/matrixTranspose ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1364 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/pointer_arithmetic ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 488 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/sumarray ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 948 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/sumarray2d ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1108 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/sumarraymalloc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1184 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/test_indvars ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1436 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/Regression/C/testtrace ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1128 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-04-17-PrintfChar ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 576 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-ArgumentTest ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 624 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-CastTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1508 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-CastTest1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 608 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-CastTest2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 736 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-CastTest3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 684 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-02-ManyArguments ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 696 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-03-NotTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 664 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-05-19-DivTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 688 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-08-02-CastTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 584 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-08-02-CastTest2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 608 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-08-19-CodegenBug ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 568 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-10-09-ArrayResolution ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 644 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-10-12-StructureArgs ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 636 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-10-12-StructureArgsSimple ? ? ? ? ? ? ? ? ? ?|
> 0.0000 604 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-10-13-BadLoad ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 572 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2002-12-13-MishaTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 584 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-04-22-Switch ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 736 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-02-DependentPHI ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 816 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-07-VarArgs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 2828 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-12-MinIntProblem ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 568 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-14-AtExit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 688 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-26-Shorts ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 2012 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-31-CastToBool ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 916 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-05-31-LongShifts ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 952 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-07-06-IntOverflow ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 812 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-07-08-BitOpsTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 592 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-07-09-LoadShorts ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1520 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-07-09-SignedArgs ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 1676 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-07-10-SignConversions ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 792 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-08-05-CastFPToUint ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 720 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-08-11-VaListArg ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 3108 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-08-20-FoldBug ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 568 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-09-18-BitFieldTest ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 612 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-10-13-SwitchTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 652 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2003-10-29-ScalarReplBug ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 580 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2004-02-02-NegativeZero ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 640 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2004-06-20-StaticBitfieldInit ? ? ? ? ? ? ? ? ? ? |
> 0.0000 684 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2004-11-28-GlobalBoolLayout ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 880 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-05-11-Popcount-ffs-fls ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 2144 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-05-12-Int64ToFP ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 684 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-05-13-SDivTwo ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 648 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-07-15-Bitfield-ABI ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 596 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-07-17-INT-To-FP ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 928 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2005-11-29-LongSwitch ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 584 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-01-23-UnionInit ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 2152 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 *
> ?0.00 * ? ? ? ? ? 0.01 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-01-29-SimpleIndirectCall ? ? ? ? ? ? ? ? ? ? |
> 0.0000 796 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-02-04-DivRem ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 672 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-12-01-float_varg ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 660 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-12-04-DynAllocAndRestore ? ? ? ? ? ? ? ? ? ? |
> 0.0100 480 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-12-07-Compare64BitConstant ? ? ? ? ? ? ? ? ? |
> 0.0000 592 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2006-12-11-LoadConstants ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0400 2704 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0400 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.04 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2007-01-04-KNR-Args ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 668 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2007-03-02-VaCopy ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 944 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2007-04-10-BitfieldTest ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 604 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2007-04-25-weak ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 512 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2008-04-18-LoopBug ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 1052 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2008-04-20-LoopBug2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1068 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2008-07-13-InlineSetjmp ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 836 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/2009-04-16-BitfieldInitialization ? ? ? ? ? ? ? ? |
> 0.0100 1900 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 *
> ?0.00 * ? ? ? ? ? 0.01 | n/a ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/AtomicOps ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 812 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/FloatPrecision ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 616 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/cast ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0200 2548 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.03 ? ?0.02
> ?0.02 * ? ? ? ? ? 0.06 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/cast-bug ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 632 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/cast2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 592 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/ccc ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 772 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.01 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/div ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 1340 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/factor ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 1008 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/rem ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0400 9136 ? ? 0.1100 ? ? ?* ? ? ? ? ? ? ? ?0.1200 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.14 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/SignlessTypes/shr ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0199 1448 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.01 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/StructModifyTest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 688 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/TestLoop ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 680 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Threads/tls ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 876 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?* ? ? ? ? ? | ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ?* ? ? ? | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/SSE/sse.expandfft ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 6440 ? ? 0.0300 ? ? ?* ? ? ? ? ? ? ? ?0.0300 ? ? ?| ? ?0.61 ? ?0.58
> ?0.54 * ? ? ? ? ? 0.60 | 1.05 ? ?1.13 ? ?n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/SSE/sse.isamax ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0300 3148 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/SSE/sse.shift ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0099 828 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/SSE/sse.stepfft ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0500 10044 ? ?0.0400 ? ? ?* ? ? ? ? ? ? ? ?0.0600 ? ? ?| ? ?0.63 ? ?0.62
> ?0.61 * ? ? ? ? ? 0.64 | 1.02 ? ?1.03 ? ?n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/build ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0000 828 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/build2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0200 1152 ? ? 0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?1.95 ? ?1.96
> ?1.95 * ? ? ? ? ? 1.93 | 0.99 ? ?1.00 ? ?n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/divides ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> 0.0100 656 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/multiplies ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1744 ? ? 0.0200 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?2.80 ? ?2.81
> ?1.84 * ? ? ? ? ? 1.85 | 1.00 ? ?1.52 ? ?n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/simple ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 1216 ? ? 0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/sumarray ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0100 920 ? ? ?0.0000 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.00 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/Vector/sumarray-dbl ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 976 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0100 ? ? ?| ? ?0.00 ? ?0.01
> ?0.00 * ? ? ? ? ? 0.02 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
> SingleSource/UnitTests/printargs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> 0.0000 760 ? ? ?0.0100 ? ? ?* ? ? ? ? ? ? ? ?0.0000 ? ? ?| ? ?0.00 ? ?0.00
> ?0.00 * ? ? ? ? ? 0.01 | - ? ? ? - ? ? ? n/a ? ? ? ? ?n/a
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu ? ? ? ? http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>



-- 
-- 
Edward O'Callaghan
http://www.auroraux.org/
eocallaghan at auroraux dot org


From regehr at cs.utah.edu  Tue Oct 20 11:04:21 2009
From: regehr at cs.utah.edu (John Regehr)
Date: Tue, 20 Oct 2009 10:04:21 -0600 (MDT)
Subject: [LLVMdev] slooow compiles
In-Reply-To: <4AA5EA99-70F5-4C33-8683-66782C75DD5C@apple.com>
References: <alpine.DEB.1.00.0910192115560.15430@memphis.cs.utah.edu>
	<4AA5EA99-70F5-4C33-8683-66782C75DD5C@apple.com>
Message-ID: <alpine.DEB.1.00.0910201004070.16016@thebes.cs.utah.edu>

Unswitch loops is the culprit, I'm about to file a bug.

John


--
John Regehr, regehr at cs.utah.edu
Associate Professor, School of Computing, University of Utah
http://www.cs.utah.edu/~regehr/

On Mon, 19 Oct 2009, Dan Gohman wrote:

> My InlineCost refactoring has been noticed in this aspect; that may or may 
> notbe the culprit here.
>
> A quick thing you can do is to compile with -ftime-report and compare the top 
> few passes between versions.
>
> Dan
>
> On Oct 19, 2009, at 8:47 PM, John Regehr <regehr at cs.utah.edu> wrote:
>
>> As part of routine testing, I run clang and llvm-gcc a lot of times.
>> Something happened between r83681 and r84167 such that clang-cc and cc1
>> became many hundreds of times slower when asked to perform optimizations.
>> 
>> Is this a known issue?  These are all release builds on Ubuntu Jaunty on
>> x86.  During these long runs, memory usage creeps up slowly at maybe 1 MB
>> per minute.
>> 
>> Thanks,
>> 
>> John Regehr
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

From richard at xmos.com  Tue Oct 20 11:10:54 2009
From: richard at xmos.com (Richard Osborne)
Date: Tue, 20 Oct 2009 17:10:54 +0100
Subject: [LLVMdev] No DWARF line number info with HasDotLocAndDotFile = true
Message-ID: <4ADDE10E.1040500@xmos.com>

It seems to me that emitting DWARF line number information using .loc 
directives is currently broken. CellSPU is currently the only in tree 
target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it 
to produce any line number information.

Is this a known issue? I understand that there are lots of changes going 
on in this area. Any idea what it would take to fix?

-- 
Richard Osborne | XMOS
http://www.xmos.com


From kennethuil at gmail.com  Tue Oct 20 11:26:28 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 20 Oct 2009 11:26:28 -0500
Subject: [LLVMdev] Target data question
Message-ID: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>

According to the "LLVM Assembly Language Reference Manual":

When constructing the data layout for a given target, LLVM starts with
a default set of specifications which are then (possibly) overriden by
the specifications in the datalayout keyword. The default
specifications are given in this list:

    * E - big endian
    * p:32:64:64 - 32-bit pointers with 64-bit alignment


Are these the specifications that are assumed by LLVM tools such as
"opt" when a module doesn't have a target data specification?  And
does that mean that "opt", when given a module without a target data
specification, might assume that GEP pointer-to-pointer, 1 should
increment that pointer by eight bytes?

From duncan.sands at math.u-psud.fr  Tue Oct 20 11:36:55 2009
From: duncan.sands at math.u-psud.fr (Duncan Sands)
Date: Tue, 20 Oct 2009 18:36:55 +0200
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
Message-ID: <4ADDE727.4080202@math.u-psud.fr>

Hi Tanya, here's another one, 32 bit this time.  I forgot to mention
that the system compiler is gcc-4.4.

> 1) Compile llvm from source and untar the llvm-test in the projects 
> directory (name it llvm-test or test-suite). Choose to use a 
> pre-compiled llvm-gcc or re-compile it yourself.

I compiled llvm and llvm-gcc with separate objects directories.
Platform is i486-linux-gnu.

> 2) Run make check, report any failures (FAIL or unexpected pass). Note 
> that you need to reconfigure llvm with llvm-gcc in your path or with 
> --with-llvmgccdir

One unexpected pass:
XPASS: 
llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11-AsmBlocksComplexJumpTarget.c

> 3) Run "make TEST=nightly report" and send me the report.nightly.txt

Attached.

Ciao,

Duncan.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report.nightly.txt
Url: http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20091020/bc0aeda1/attachment.txt 

From richard at xmos.com  Tue Oct 20 11:52:29 2009
From: richard at xmos.com (Richard Osborne)
Date: Tue, 20 Oct 2009 17:52:29 +0100
Subject: [LLVMdev] No DWARF line number info with HasDotLocAndDotFile =
	true
In-Reply-To: <4ADDE10E.1040500@xmos.com>
References: <4ADDE10E.1040500@xmos.com>
Message-ID: <4ADDEACD.70406@xmos.com>

Richard Osborne wrote:
> It seems to me that emitting DWARF line number information using .loc 
> directives is currently broken. CellSPU is currently the only in tree 
> target that sets HasDotLocAndDotFile in its MCAsmInfo and I can't get it 
> to produce any line number information.
>   
I think I understand why this is happening. Since HasDotLocAndDotFile is 
set the DwarfDebug class doesn't emit the line number table as a series 
of bytes:

  // If the target is using .loc/.file, the assembler will be emitting the
  // .debug_line table automatically.
  if (MAI->hasDotLocAndDotFile())
    return;

Previously .loc directives are printed by selecting ISD::DEBUG_LOC nodes 
to pseudo instructions which print as the directive. For example:

def DWARF_LOC : Pseudo<(outs), (ins i32imm:$line, i32imm:$col, 
i32imm:$file),
           ".loc $file, $line, $col",
           [(dwarf_loc (i32 imm:$line), (i32 imm:$col), (i32 imm:$file))]>;

ISD::DEBUG_LOC nodes are produced when debug stoppoints are expanded. 
However debug stoppoints are no longer produced by the frontend since 
debug info is now encoded using metadata. Therefore there are no .loc 
directives in the output and no line number information.

It looks like AsmPrinter::processDebugLoc function should be updated to 
check whether HasDotLocAndDotFile is set and if it is emit the .loc 
directive.

Does this make sense?

-- 
Richard Osborne | XMOS
http://www.xmos.com


From kennethuil at gmail.com  Tue Oct 20 12:08:19 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 20 Oct 2009 12:08:19 -0500
Subject: [LLVMdev] Target data question
In-Reply-To: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
Message-ID: <400d33ea0910201008h3bde2fc8t8e4005f66f93e1a9@mail.gmail.com>

On Tue, Oct 20, 2009 at 11:26 AM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> According to the "LLVM Assembly Language Reference Manual":
>
> When constructing the data layout for a given target, LLVM starts with
> a default set of specifications which are then (possibly) overriden by
> the specifications in the datalayout keyword. The default
> specifications are given in this list:
>
> ? ?* E - big endian
> ? ?* p:32:64:64 - 32-bit pointers with 64-bit alignment
>
>
> Are these the specifications that are assumed by LLVM tools such as
> "opt" when a module doesn't have a target data specification? ?And
> does that mean that "opt", when given a module without a target data
> specification, might assume that GEP pointer-to-pointer, 1 should
> increment that pointer by eight bytes?

If anyone else was waiting for the answer...

The answer is yes.  "opt" uses the same default target data layout
regardless of what host machine it's being run on, and it'll trash any
pointer indexing you're trying to do if you're running on a real
machine whose target data layout is different from the universal
default and your module doesn't have a target data layout specified.

I hardcoded the layout by copying-and-pasting one generated by
llvm-gcc.  Now I'm off to dig up how to get the layout string for the
platform you're running on...


From gohman at apple.com  Tue Oct 20 12:08:14 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 20 Oct 2009 10:08:14 -0700
Subject: [LLVMdev] Target data question
In-Reply-To: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
Message-ID: <1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>


On Oct 20, 2009, at 9:26 AM, Kenneth Uildriks wrote:

> According to the "LLVM Assembly Language Reference Manual":
>
> When constructing the data layout for a given target, LLVM starts with
> a default set of specifications which are then (possibly) overriden by
> the specifications in the datalayout keyword. The default
> specifications are given in this list:
>
>    * E - big endian
>    * p:32:64:64 - 32-bit pointers with 64-bit alignment
>
>
> Are these the specifications that are assumed by LLVM tools such as
> "opt" when a module doesn't have a target data specification?  And
> does that mean that "opt", when given a module without a target data
> specification, might assume that GEP pointer-to-pointer, 1 should
> increment that pointer by eight bytes?

Unfortunately, yes.  See PR4542.  Progress has been made recently
though -- the optimizers are now ready.  The main things left to do
is to update the documentation and update the testsuite to account
for the change in the meaning of a module without a targetdata string.

Dan


From kennethuil at gmail.com  Tue Oct 20 12:13:21 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 20 Oct 2009 12:13:21 -0500
Subject: [LLVMdev] Target data question
In-Reply-To: <1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
	<1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>
Message-ID: <400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>

On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote:
> Unfortunately, yes. ?See PR4542. ?Progress has been made recently
> though -- the optimizers are now ready. ?The main things left to do
> is to update the documentation and update the testsuite to account
> for the change in the meaning of a module without a targetdata string.
>
> Dan
>
>

So in the near future, the optimizers won't do any target-specific
transformations in the absence of module target data?


From kennethuil at gmail.com  Tue Oct 20 12:36:19 2009
From: kennethuil at gmail.com (Kenneth Uildriks)
Date: Tue, 20 Oct 2009 12:36:19 -0500
Subject: [LLVMdev] Target data question
In-Reply-To: <400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
	<1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>
	<400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>
Message-ID: <400d33ea0910201036r49323b7cjc67bbf7fa101a7d2@mail.gmail.com>

On Tue, Oct 20, 2009 at 12:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote:
>> Unfortunately, yes. ?See PR4542. ?Progress has been made recently
>> though -- the optimizers are now ready. ?The main things left to do
>> is to update the documentation and update the testsuite to account
>> for the change in the meaning of a module without a targetdata string.
>>
>> Dan
>>
>>
>
> So in the near future, the optimizers won't do any target-specific
> transformations in the absence of module target data?
>

Also, has anyone passed a target data string to "opt" with
-targetdata?  I'm trying that out now and getting "Too many positional
arguments specified!".  I've tried escaping all the dashes in the
target data string... no luck


From lattner at apple.com  Tue Oct 20 12:45:41 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 20 Oct 2009 10:45:41 -0700
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <521640720910200745pde9cdcu143a2917431599af@mail.gmail.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<4ADDB4D4.5010504@free.fr>
	<521640720910200745pde9cdcu143a2917431599af@mail.gmail.com>
Message-ID: <CF7ED95F-ED7D-486A-AD37-F30769F6CBB9@apple.com>


On Oct 20, 2009, at 7:45 AM, Edward O'Callaghan wrote:

> G'Day Tanya,
>
> Is it too late to bring in the following patches to fix some major
> brokenness in the AuroraUX tool chain for 2.6?
>

Yes, it is too late.

At this stage in the process, we only accept patches that fix  
regressions on supported targets for the release as defined here:
http://llvm.org/docs/HowToReleaseLLVM.html#release-qualify

-Tanya


> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84468&r2=84469&view=diff&pathrev=84469
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?r1=84265&r2=84266&view=diff&pathrev=84266
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitHeaderSearch.cpp?r1=83846&r2=83847&view=diff&pathrev=83847
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?r1=84415&r2=84416&view=diff&pathrev=84416
>
> All should be completely non intrusive.
>
> Thanks for your time,
> Edward O'Callaghan.
>
> 2009/10/20 Duncan Sands <baldrick at free.fr>:
>> Hi Tanya,
>>
>>> 1) Compile llvm from source and untar the llvm-test in the projects
>>> directory (name it llvm-test or test-suite). Choose to use a pre- 
>>> compiled
>>> llvm-gcc or re-compile it yourself.
>>
>> I compiled llvm and llvm-gcc with separate objects directories.
>> Platform is x86_64-linux-gnu.
>>
>>> 2) Run make check, report any failures (FAIL or unexpected pass).  
>>> Note
>>> that you need to reconfigure llvm with llvm-gcc in your path or with
>>> --with-llvmgccdir
>>
>> One failure:
>>
>> FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
>> Failed with exit(1) at line 1
>> while running:  llvm-as < llvm-2.6/llvm-2.6/test/Feature/ 
>> load_module.ll |
>>  opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/LLVMHello.so -hello
>> -disable-output - |& /bin/grep Hello
>> Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so':
>> llvm-2.6-objects/Release/lib/LLVMHello.so: undefined symbol:  
>> _ZN4llvm4cerrE
>> child process exited abnormally
>>
>> One unexpected pass:
>>
>> XPASS:
>> llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11- 
>> AsmBlocksComplexJumpTarget.c
>>
>>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>>
>> Attached.
>>
>> Ciao,
>>
>> Duncan.
>>
>> Program 
>>                                                                   |
>> GCCAS  Bytecode LLC compile LLC-BETA compile JIT codegen | GCC      
>> CBE
>> LLC     LLC-BETA JIT     | GCC/CBE GCC/LLC GCC/LLC-BETA LLC/LLC-BETA
>> MultiSource/Applications/Burg/ 
>> burg                                       |
>> 0.4400 112068   0.9899      *                1.0100      |     
>> 0.00    0.00
>>  0.01 *           1.06 | -       -       n/a          n/a
>> MultiSource/Applications/ClamAV/ 
>> clamscan                                 |
>> 4.7699 1321972  8.1600      *                4.5900      |    0.37 *
>>  0.21 *           4.98 | n/a     1.76    n/a          n/a
>> MultiSource/Applications/JM/ldecod/ 
>> ldecod                                |
>> 2.6799 664468   3.1200      *                2.5700      |     
>> 0.12    0.11
>>  0.12 *           2.82 | 1.09    1.00    n/a          n/a
>> MultiSource/Applications/JM/lencod/ 
>> lencod                                |
>> 5.6600 1462632  7.7899      *                6.5999      |     
>> 9.73    9.01
>>  8.99 *          16.29 | 1.08    1.08    n/a          n/a
>> MultiSource/Applications/SIBsim4/ 
>> SIBsim4                                 |
>> 0.4700 88500    0.5400      *                0.5399      |    4.91 *
>>  4.55 *           5.41 | n/a     1.08    n/a          n/a
>> MultiSource/Applications/SPASS/ 
>> SPASS                                     |
>> 6.5800 1603628  6.6600      *                4.6100      |    
>> 10.54   10.00
>>  9.98 *          15.63 | 1.05    1.06    n/a          n/a
>> MultiSource/Applications/aha/ 
>> aha                                         |
>> 0.0499 7356     0.0300      *                0.0500      |     
>> 3.23    2.97
>>  2.78 *           3.26 | 1.09    1.16    n/a          n/a
>> MultiSource/Applications/d/ 
>> make_dparser                                  |
>> 1.1100 311092   1.1700      *                1.0100      |    0.03 *
>>  0.03 *           1.14 | n/a     -       n/a          n/a
>> MultiSource/Applications/hbd/ 
>> hbd                                         |
>> 0.2500 82224    0.3999      *                0.3400      |     
>> 0.00    0.00
>>  0.00 *           0.39 | -       -       n/a          n/a
>> MultiSource/Applications/hexxagon/ 
>> hexxagon                               |
>> 0.2000 49988    0.2600      *                0.2399      |    
>> 12.80    9.91
>>  9.62 *           9.42 | 1.29    1.33    n/a          n/a
>>                        llc:
>> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
>> CBackend.cpp:488:
>> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
>> (llvm::formatted_raw_ostream&,
>> const llvm::Type*, bool, const std::string&): Assertion `NumBits <=  
>> 128 &&
>> "Bit widths > 128 not implemented yet"' failed.
>> MultiSource/Applications/kimwitu++/ 
>> kc                                    |
>> 5.7400 1722276  8.1900      *                5.5100      |    0.18 *
>>  0.14 *           6.17 | n/a     1.29    n/a          n/a
>> MultiSource/Applications/lambda-0.1.3/ 
>> lambda                             |
>> 0.2100 66708    0.4300      *                0.3199      |     
>> 5.30    5.31
>>  5.36 *           6.34 | 1.00    0.99    n/a          n/a
>> MultiSource/Applications/lemon/ 
>> lemon                                     |
>> 0.4200 108608   0.6300      *                0.0100      |     
>> 0.07    0.07
>>  0.06 *         133.28 | -       -       n/a          n/a
>> MultiSource/Applications/lua/ 
>> lua                                         |
>> 1.7100 547448   2.8600      *                2.0899      |   27.89 *
>> 27.87 *          30.62 | n/a     1.00    n/a          n/a
>> MultiSource/Applications/minisat/ 
>> minisat                                 |
>> 0.2800 47664    0.2700      *                *           |    8.31 *
>>  8.28 *        *       | n/a     1.00    n/a          n/a
>> MultiSource/Applications/obsequi/ 
>> Obsequi                                 |
>> 0.3600 61068    0.3499      *                0.3200      |    2.55 *
>>  2.48 *           3.00 | n/a     1.03    n/a          n/a
>> MultiSource/Applications/oggenc/ 
>> oggenc                                   |
>> 1.5600 815432   1.3699      *                1.1900      |    0.19 *
>>  0.18 *           1.50 | n/a     1.06    n/a          n/a
>> MultiSource/Applications/sgefa/ 
>> sgefa                                     |
>> 0.1200 17048    0.1099      *                0.1199      |     
>> 0.84    0.85
>>  0.84 *           1.00 | 0.99    1.00    n/a          n/a
>> MultiSource/Applications/siod/ 
>> siod                                       |
>> 0.7600 344780   2.4000      *                0.9599      |     
>> 3.46    3.25
>>  3.42 *           4.62 | 1.06    1.01    n/a          n/a
>> MultiSource/Applications/spiff/ 
>> spiff                                     |
>> 0.2000 51480    0.3100      *                *           |     
>> 0.94    0.93
>>  0.96 *        *       | 1.01    0.98    n/a          n/a
>> MultiSource/Applications/sqlite3/ 
>> sqlite3                                 |
>> 3.6800 1139780  6.3700      *                4.6300      |    5.10 *
>>  5.15 *          10.40 | n/a     0.99    n/a          n/a
>> MultiSource/Applications/treecc/ 
>> treecc                                   |
>> 0.7200 287712   1.5700      *                0.4299      |     
>> 0.00    0.00
>>  0.00 *           0.47 | -       -       n/a          n/a
>> MultiSource/Applications/viterbi/ 
>> viterbi                                 |
>> 0.0499 5460     0.0400      *                0.0300      |    
>> 11.62   11.68
>> 11.81 *          11.87 | 0.99    0.98    n/a          n/a
>> MultiSource/Benchmarks/ASCI_Purple/SMG2000/ 
>> smg2000                       |
>> 2.9899 498940   3.0500      *                2.2999      |     
>> 4.51    4.23
>>  4.44 *           6.71 | 1.07    1.02    n/a          n/a
>> MultiSource/Benchmarks/ASC_Sequoia/AMGmk/ 
>> AMGmk                           |
>> 0.0999 14168    0.0800      *                0.0799      |    
>> 15.60   15.84
>> 15.72 *          15.78 | 0.98    0.99    n/a          n/a
>> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/ 
>> CrystalMk                   |
>> 0.0500 8296     0.0500      *                0.0300      |     
>> 8.83    8.73
>>  8.69 *           8.77 | 1.01    1.02    n/a          n/a
>> MultiSource/Benchmarks/ASC_Sequoia/IRSmk/ 
>> IRSmk                           |
>> 0.0100 5600     0.0300      *                0.0300      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> MultiSource/Benchmarks/BitBench/drop3/ 
>> drop3                              |
>> 0.0200 3592     0.0199      *                0.0200      |     
>> 0.48    0.66
>>  0.46 *           0.49 | 0.73    1.04    n/a          n/a
>> MultiSource/Benchmarks/BitBench/five11/ 
>> five11                            |
>> 0.0000 2768     0.0100      *                0.0100      |     
>> 2.33    2.44
>>  2.27 *           2.39 | 0.95    1.03    n/a          n/a
>> MultiSource/Benchmarks/BitBench/uudecode/ 
>> uudecode                        |
>> 0.0200 2968     0.0100      *                0.0000      |     
>> 0.13    0.12
>>  0.14 *           0.14 | 1.08    0.93    n/a          n/a
>> MultiSource/Benchmarks/BitBench/uuencode/ 
>> uuencode                        |
>> 0.0200 2764     0.0200      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Fhourstones-3.1/ 
>> fhourstones3.1                    |
>> 0.0500 8160     0.0500      *                0.0500      |     
>> 1.63    1.70
>>  1.58 *           1.64 | 0.96    1.03    n/a          n/a
>> MultiSource/Benchmarks/Fhourstones/ 
>> fhourstones                           |
>> 0.0699 11088    0.0600      *                0.0500      |     
>> 1.42    1.32
>>  1.33 *           1.39 | 1.08    1.07    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/analyzer/ 
>> analyzer                       |
>> 0.0600 10052    0.0600      *                0.0600      |     
>> 0.14    0.14
>>  0.12 *           0.18 | 1.00    1.17    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/distray/ 
>> distray                         |
>> 0.0200 6952     0.0300      *                0.0300      |     
>> 0.16    0.17
>>  0.18 *           0.23 | 0.94    0.89    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/fourinarow/ 
>> fourinarow                   |
>> 0.1099 18888    0.1199      *                0.0900      |     
>> 0.36    0.35
>>  0.37 *           0.47 | 1.03    0.97    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/mason/ 
>> mason                             |
>> 0.0300 6148     0.0200      *                0.0300      |     
>> 0.23    0.26
>>  0.25 *           0.29 | 0.88    0.92    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/neural/ 
>> neural                           |
>> 0.0700 9712     0.0500      *                0.0699      |     
>> 0.24    0.27
>>  0.23 *           0.34 | 0.89    1.04    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/pcompress2/ 
>> pcompress2                   |
>> 0.0599 11084    0.0500      *                0.0600      |     
>> 0.23    0.21
>>  0.21 *           0.29 | 1.10    1.10    n/a          n/a
>> MultiSource/Benchmarks/FreeBench/pifft/ 
>> pifft                             |
>> 0.2900 60776    0.3400      *                0.3300      |     
>> 0.14    0.14
>>  0.14 *           0.50 | 1.00    1.00    n/a          n/a
>> MultiSource/Benchmarks/MallocBench/cfrac/ 
>> cfrac                           |
>> 0.2100 92260    0.3600      *                0.3500      |     
>> 1.44    1.44
>>  1.38 *           1.80 | 1.00    1.04    n/a          n/a
>> MultiSource/Benchmarks/MallocBench/espresso/ 
>> espresso                     |
>> 1.4700 414748   2.4299      *                1.6400      |     
>> 0.61    0.55
>>  0.54 *           2.27 | 1.11    1.13    n/a          n/a
>>                        llc:
>> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
>> CBackend.cpp:488:
>> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
>> (llvm::formatted_raw_ostream&,
>> const llvm::Type*, bool, const std::string&): Assertion `NumBits <=  
>> 128 &&
>> "Bit widths > 128 not implemented yet"' failed.
>> MultiSource/Benchmarks/MallocBench/gs/ 
>> gs                                 |
>> 1.2000 376224   1.7600      *                0.7900      |    0.07 *
>>  0.06 *           0.95 | n/a     -       n/a          n/a
>> MultiSource/Benchmarks/McCat/01-qbsort/ 
>> qbsort                            |
>> 0.0099 3600     0.0200      *                0.0300      |     
>> 0.07    0.06
>>  0.05 *           0.10 | -       -       n/a          n/a
>> MultiSource/Benchmarks/McCat/03-testtrie/ 
>> testtrie                        |
>> 0.0200 3756     0.0100      *                0.0300      |     
>> 0.02    0.01
>>  0.01 *           0.04 | -       -       n/a          n/a
>> MultiSource/Benchmarks/McCat/04-bisect/ 
>> bisect                            |
>> 0.0300 4036     0.0400      *                0.0199      |     
>> 0.14    0.13
>>  0.13 *           0.17 | 1.08    1.08    n/a          n/a
>> MultiSource/Benchmarks/McCat/05-eks/ 
>> eks                                  |
>> 0.0999 7888     0.0500      *                0.0500      |     
>> 0.01    0.00
>>  0.02 *           0.06 | -       -       n/a          n/a
>> MultiSource/Benchmarks/McCat/08-main/ 
>> main                                |
>> 0.0900 11928    0.0500      *                0.0599      |     
>> 0.07    0.03
>>  0.03 *           0.09 | -       -       n/a          n/a
>> MultiSource/Benchmarks/McCat/09-vor/ 
>> vor                                  |
>> 0.0999 23148    0.1300      *                0.1200      |     
>> 0.15    0.12
>>  0.11 *           0.25 | 1.25    1.36    n/a          n/a
>> MultiSource/Benchmarks/McCat/12-IOtest/ 
>> iotest                            |
>> 0.0199 2176     0.0100      *                0.0200      |     
>> 0.33    0.23
>>  0.20 *           0.23 | 1.43    1.65    n/a          n/a
>> MultiSource/Benchmarks/McCat/15-trie/ 
>> trie                                |
>> 0.0100 3216     0.0300      *                0.0300      |     
>> 0.00    0.00
>>  0.00 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/McCat/17-bintr/ 
>> bintr                              |
>> 0.0199 3676     0.0199      *                0.0300      |     
>> 0.11    0.10
>>  0.11 *           0.13 | 1.10    1.00    n/a          n/a
>> MultiSource/Benchmarks/McCat/18-imp/ 
>> imp                                  |
>> 0.0999 21512    0.1099      *                0.1200      |    0.07 *
>>  0.08 *           0.20 | n/a     -       n/a          n/a
>>                        llc:
>> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
>> CBackend.cpp:488:
>> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
>> (llvm::formatted_raw_ostream&,
>> const llvm::Type*, bool, const std::string&): Assertion `NumBits <=  
>> 128 &&
>> "Bit widths > 128 not implemented yet"' failed.
>> MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive- 
>> basicmath |
>> 0.0200 4816     0.0300      *                0.0400      |     
>> 0.40    0.39
>>  0.39 *           0.44 | 1.03    1.03    n/a          n/a
>> MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive- 
>> bitcount   |
>> 0.0300 3540     0.0200      *                0.0399      |     
>> 0.13    0.13
>>  0.15 *           0.19 | 1.00    0.87    n/a          n/a
>> MultiSource/Benchmarks/MiBench/automotive-susan/automotive- 
>> susan         |
>> 0.2500 64756    0.3100      *                0.3200      |     
>> 0.07    0.06
>>  0.05 *           0.38 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer- 
>> jpeg               |
>> 1.2500 205708   0.9300      *                0.4900      |     
>> 0.02    0.01
>>  0.01 *           0.54 | -       -       n/a          n/a
>>                        llc:
>> /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
>> CBackend.cpp:488:
>> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
>> (llvm::formatted_raw_ostream&,
>> const llvm::Type*, bool, const std::string&): Assertion `NumBits <=  
>> 128 &&
>> "Bit widths > 128 not implemented yet"' failed.
>> MultiSource/Benchmarks/MiBench/consumer-lame/consumer- 
>> lame               |
>> 1.3200 335108   1.3200      *                1.2100      |    0.28 *
>>  0.27 *           1.58 | n/a     1.04    n/a          n/a
>> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer- 
>> typeset         |
>> 5.7999 1397316  6.9899      *                6.0300      |    0.35 *
>>  0.22 *           6.47 | n/a     1.59    n/a          n/a
>> MultiSource/Benchmarks/MiBench/network-dijkstra/network- 
>> dijkstra         |
>> 0.0100 3512     0.0300      *                0.0200      |     
>> 0.04    0.05
>>  0.05 *           0.07 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/network-patricia/network- 
>> patricia         |
>> 0.0300 4248     0.0300      *                0.0200      |     
>> 0.14    0.12
>>  0.12 *           0.16 | 1.17    1.17    n/a          n/a
>> MultiSource/Benchmarks/MiBench/office-ispell/office- 
>> ispell               |
>> 0.5400 128620   0.7899      *                0.2400      |     
>> 0.01    0.00
>>  0.00 *           0.26 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/office-stringsearch/office- 
>> stringsearch   |
>> 0.0200 13232    0.0199      *                0.0300      |     
>> 0.00    0.01
>>  0.00 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/security-blowfish/security- 
>> blowfish       |
>> 0.0999 30936    0.1099      *                0.0600      |     
>> 0.01    0.00
>>  0.00 *           0.07 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/security-rijndael/security- 
>> rijndael       |
>> 0.1400 51232    0.1000      *                0.0700      |     
>> 0.08    0.06
>>  0.07 *           0.16 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/security-sha/security- 
>> sha                 |
>> 0.0300 4760     0.0300      *                0.0300      |     
>> 0.07    0.03
>>  0.03 *           0.05 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm- 
>> CRC32             |
>> 0.0000 3180     0.0100      *                0.0000      |     
>> 0.41    0.28
>>  0.28 *           0.30 | 1.46    1.46    n/a          n/a
>> MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm- 
>> fft                 |
>> 0.0200 4880     0.0300      *                0.0199      |     
>> 0.06    0.07
>>  0.06 *           0.09 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/telecomm-adpcm/telecomm- 
>> adpcm             |
>> 0.0000 2196     0.0100      *                0.0100      |     
>> 0.01    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm- 
>> gsm                 |
>> 0.3500 76716    0.3299      *                0.1900      |     
>> 0.23    0.24
>>  0.23 *           0.43 | 0.96    1.00    n/a          n/a
>> MultiSource/Benchmarks/NPB-serial/is/ 
>> is                                  |
>> 0.0099 5116     0.0300      *                0.3599      |    
>> 10.08    9.85
>>  9.84 *          10.18 | 1.02    1.02    n/a          n/a
>> MultiSource/Benchmarks/Olden/bh/ 
>> bh                                       |
>> 0.1199 15308    0.0800      *                0.0699      |    1.97 *
>>  1.57 *           1.67 | n/a     1.25    n/a          n/a
>> MultiSource/Benchmarks/Olden/bisort/ 
>> bisort                               |
>> 0.0100 3688     0.0199      *                0.0200      |     
>> 0.80    0.82
>>  0.79 *           0.81 | 0.98    1.01    n/a          n/a
>> MultiSource/Benchmarks/Olden/em3d/ 
>> em3d                                   |
>> 0.0400 6412     0.0400      *                0.0499      |     
>> 3.30    3.29
>>  3.29 *           3.32 | 1.00    1.00    n/a          n/a
>> MultiSource/Benchmarks/Olden/health/ 
>> health                               |
>> 0.0300 7608     0.0400      *                0.0300      |    0.52 *
>>  0.50 *           0.54 | n/a     1.04    n/a          n/a
>> MultiSource/Benchmarks/Olden/mst/ 
>> mst                                     |
>> 0.0500 4176     0.0300      *                0.0300      |     
>> 0.15    0.14
>>  0.14 *           0.18 | 1.07    1.07    n/a          n/a
>> MultiSource/Benchmarks/Olden/perimeter/ 
>> perimeter                         |
>> 0.0000 12340    0.0799      *                0.0699      |     
>> 0.36    0.34
>>  0.32 *           0.38 | 1.06    1.12    n/a          n/a
>> MultiSource/Benchmarks/Olden/power/ 
>> power                                 |
>> 0.0200 8564     0.0300      *                0.0300      |     
>> 1.56    1.55
>>  1.52 *           1.57 | 1.01    1.03    n/a          n/a
>> MultiSource/Benchmarks/Olden/treeadd/ 
>> treeadd                             |
>> 0.0100 1824     0.0200      *                0.0200      |     
>> 0.33    0.34
>>  0.34 *           0.34 | 0.97    0.97    n/a          n/a
>> MultiSource/Benchmarks/Olden/tsp/ 
>> tsp                                     |
>> 0.0300 6988     0.0300      *                0.0200      |     
>> 1.15    1.13
>>  1.14 *           1.16 | 1.02    1.01    n/a          n/a
>> MultiSource/Benchmarks/Olden/voronoi/ 
>> voronoi                             |
>> 0.0900 13436    0.0500      *                0.0400      |     
>> 0.42    0.41
>>  0.42 *           0.48 | 1.02    1.00    n/a          n/a
>> MultiSource/Benchmarks/OptimizerEval/optimizer- 
>> eval                      |
>> 0.0800 29224    0.1500      *                0.1800      |  106.85   
>> 110.58
>>  109.30 *          96.14 | 0.97    0.98    n/a          n/a
>> MultiSource/Benchmarks/PAQ8p/ 
>> paq8p                                       |
>> 0.9300 198188   1.0400      *                *           |    0.00 *
>>  0.01 *        *       | n/a     -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/NP/ 
>> np                                |
>> 0.0000 1188     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/city/ 
>> city                            |
>> 0.1199 23708    0.0800      *                0.0699      |     
>> 0.01    0.01
>>  0.00 *           0.09 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/deriv1/ 
>> deriv1                        |
>> 0.0600 12928    0.0500      *                0.0600      |     
>> 0.01    0.00
>>  0.00 *           0.06 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/deriv2/ 
>> deriv2                        |
>> 0.0400 14480    0.0700      *                0.0499      |     
>> 0.00    0.00
>>  0.00 *           0.07 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/employ/ 
>> employ                        |
>> 0.1000 21900    0.1099      *                0.0799      |     
>> 0.02    0.01
>>  0.01 *           0.10 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/family/ 
>> family                        |
>> 0.0300 3388     0.0200      *                0.0199      |     
>> 0.00    0.01
>>  0.00 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/fsm/ 
>> fsm                              |
>> 0.0100 1904     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/garage/ 
>> garage                        |
>> 0.0499 7428     0.0400      *                0.0400      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/life/ 
>> life                            |
>> 0.0200 6324     0.0300      *                0.0100      |     
>> 1.38    1.44
>>  1.45 *           1.48 | 0.96    0.95    n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/objects/ 
>> objects                      |
>> 0.0300 9980     0.0500      *                0.0200      |     
>> 0.00    0.01
>>  0.00 *           0.02 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/ocean/ 
>> ocean                          |
>> 0.0200 8880     0.0500      *                0.0399      |     
>> 0.12    0.11
>>  0.12 *           0.16 | 1.09    1.00    n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/office/ 
>> office                        |
>> 0.0400 12924    0.0699      *                0.0500      |     
>> 0.00    0.00
>>  0.00 *           0.06 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/primes/ 
>> primes                        |
>> 0.0100 1584     0.0100      *                0.0100      |     
>> 0.37    0.35
>>  0.35 *           0.37 | 1.06    1.06    n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/shapes/ 
>> shapes                        |
>> 0.0399 16268    0.0899      *                0.0699      |     
>> 0.01    0.01
>>  0.01 *           0.08 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/simul/ 
>> simul                          |
>> 0.0600 4176     0.0200      *                0.0100      |     
>> 0.01    0.01
>>  0.01 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/trees/ 
>> trees                          |
>> 0.0500 11288    0.0700      *                0.0500      |     
>> 0.00    0.01
>>  0.00 *           0.06 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C++/vcirc/ 
>> vcirc                          |
>> 0.0100 1768     0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.02 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/ 
>> timberwolfmc              |
>> 1.7300 563480   3.2999      *                0.5900      |     
>> 0.01    0.00
>>  0.00 *           0.63 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/agrep/ 
>> agrep                            |
>> 0.3700 92964    0.5300      *                0.1999      |     
>> 0.02    0.01
>>  0.01 *           0.23 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/allroots/ 
>> allroots                      |
>> 0.0200 3556     0.0200      *                0.0200      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/archie-client/ 
>> archie                   |
>> 0.2000 47648    0.2199      *                0.0600      |    0.01 *
>>  0.00 *           0.07 | n/a     -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/assembler/ 
>> assembler                    |
>> 0.1600 61544    0.3900      *                0.2999      |     
>> 0.00    0.00
>>  0.00 *           0.33 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/bison/ 
>> mybison                          |
>> 0.3600 112424   0.9900      *                0.9100      |     
>> 0.00    0.00
>>  0.00 *           0.95 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/cdecl/ 
>> cdecl                            |
>> 0.0999 48484    0.3199      *                0.3400      |     
>> 0.01    0.00
>>  0.00 *           0.35 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/compiler/ 
>> compiler                      |
>> 0.1100 36440    0.2900      *                0.0500      |     
>> 0.00    0.00
>>  0.00 *           0.06 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/fixoutput/ 
>> fixoutput                    |
>> 0.0100 6044     0.0400      *                0.0200      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/football/ 
>> football                      |
>> 0.3500 85712    0.5500      *                0.0400      |     
>> 0.00    0.00
>>  0.01 *           0.05 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/gnugo/ 
>> gnugo                            |
>> 0.1400 35692    0.2100      *                0.2200      |     
>> 0.07    0.07
>>  0.07 *           0.30 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/loader/ 
>> loader                          |
>> 0.0899 28276    0.1400      *                0.1199      |     
>> 0.00    0.00
>>  0.00 *           0.14 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/plot2fig/ 
>> plot2fig                      |
>> 0.0500 14756    0.0900      *                0.0999      |     
>> 0.00    0.00
>>  0.01 *           0.11 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/simulator/ 
>> simulator                    |
>> 0.2600 64712    0.4000      *                0.0500      |     
>> 0.00    0.01
>>  0.00 *           0.07 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/unix-smail/unix- 
>> smail                  |
>> 0.1100 39652    0.3000      *                0.2000      |     
>> 0.00    0.01
>>  0.00 *           0.22 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Prolangs-C/unix-tbl/unix- 
>> tbl                      |
>> 0.3000 78708    0.4900      *                0.0200      |     
>> 0.00    0.00
>>  0.01 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/Ptrdist/anagram/ 
>> anagram                           |
>> 0.0500 7764     0.0500      *                0.0300      |     
>> 1.46    0.97
>>  1.38 *           1.36 | 1.51    1.06    n/a          n/a
>> MultiSource/Benchmarks/Ptrdist/bc/ 
>> bc                                     |
>> 0.3300 126012   0.7700      *                0.7100      |     
>> 0.66    0.68
>>  0.64 *           1.41 | 0.97    1.03    n/a          n/a
>> MultiSource/Benchmarks/Ptrdist/ft/ 
>> ft                                     |
>> 0.0600 7236     0.0500      *                0.0400      |     
>> 1.17    1.22
>>  1.27 *           1.28 | 0.96    0.92    n/a          n/a
>> MultiSource/Benchmarks/Ptrdist/ks/ 
>> ks                                     |
>> 0.0299 11912    0.0699      *                0.0700      |     
>> 2.23    1.44
>>  2.26 *           2.21 | 1.55    0.99    n/a          n/a
>> MultiSource/Benchmarks/Ptrdist/yacr2/ 
>> yacr2                               |
>> 0.2200 48228    0.3600      *                0.3100      |     
>> 1.23    1.10
>>  1.22 *           1.56 | 1.12    1.01    n/a          n/a
>> MultiSource/Benchmarks/SciMark2-C/ 
>> scimark2                               |
>> 0.1099 15340    0.0799      *                0.0999      |   27.62 *
>> 27.38 *          27.87 | n/a     1.01    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/enc-3des/ 
>> enc-3des                        |
>> 0.1599 21456    0.1000      *                0.1200      |     
>> 2.23    2.10
>>  2.14 *           2.31 | 1.06    1.04    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/enc-md5/enc- 
>> md5                          |
>> 0.0599 7692     0.0400      *                0.0400      |     
>> 2.16    2.04
>>  2.05 *           2.21 | 1.06    1.05    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/enc-pc1/enc- 
>> pc1                          |
>> 0.0300 3964     0.0199      *                0.0300      |     
>> 1.39    0.97
>>  0.92 *           0.95 | 1.43    1.51    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/enc-rc4/enc- 
>> rc4                          |
>> 0.0000 2960     0.0100      *                0.0100      |     
>> 1.18    1.20
>>  1.16 *           1.24 | 0.98    1.02    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/netbench-crc/netbench- 
>> crc                |
>> 0.0000 32680    0.0100      *                0.0100      |     
>> 1.01    1.00
>>  1.09 *           1.07 | 1.01    0.93    n/a          n/a
>> MultiSource/Benchmarks/Trimaran/netbench-url/netbench- 
>> url                |
>> 0.0400 40832    0.0500      *                0.0400      |     
>> 3.89    3.45
>>  3.88 *           3.94 | 1.13    1.00    n/a          n/a
>> MultiSource/Benchmarks/VersaBench/8b10b/ 
>> 8b10b                            |
>> 0.0000 2240     0.0100      *                0.0100      |     
>> 7.07    4.94
>>  4.99 *           4.97 | 1.43    1.42    n/a          n/a
>> MultiSource/Benchmarks/VersaBench/beamformer/ 
>> beamformer                  |
>> 0.0400 5764     0.0300      *                0.0300      |     
>> 1.85    1.92
>>  1.76 *           1.80 | 0.96    1.05    n/a          n/a
>> MultiSource/Benchmarks/VersaBench/bmm/ 
>> bmm                                |
>> 0.0199 2896     0.0100      *                0.0300      |     
>> 2.34    2.35
>>  2.36 *           2.39 | 1.00    0.99    n/a          n/a
>> MultiSource/Benchmarks/VersaBench/dbms/ 
>> dbms                              |
>> 0.1200 36468    0.2500      *                0.2400      |     
>> 2.34    2.23
>>  2.17 *           2.35 | 1.05    1.08    n/a          n/a
>> MultiSource/Benchmarks/VersaBench/ecbdes/ 
>> ecbdes                          |
>> 0.0599 9740     0.0200      *                0.0200      |     
>> 2.87    2.91
>>  2.77 *           2.76 | 0.99    1.04    n/a          n/a
>> MultiSource/Benchmarks/llubenchmark/ 
>> llu                                  |
>> 0.0000 3896     0.0300      *                0.0300      |     
>> 6.10    6.30
>>  6.24 *           6.31 | 0.97    0.98    n/a          n/a
>> MultiSource/Benchmarks/mafft/ 
>> pairlocalalign                              |
>> 3.7200 346176   1.9100      *                *           |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/adpcm/rawcaudio/ 
>> rawcaudio              |
>> 0.0100 2324     0.0100      *                0.0100      |     
>> 0.00    0.01
>>  0.01 *           0.03 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/ 
>> rawdaudio              |
>> 0.0100 2196     0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/g721/g721encode/ 
>> encode                 |
>> 0.0600 13104    0.0800      *                0.0600      |     
>> 0.09    0.09
>>  0.08 *           0.14 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/gsm/toast/ 
>> toast                        |
>> 0.3800 76716    0.2700      *                0.2099      |     
>> 0.06    0.04
>>  0.03 *           0.24 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/ 
>> cjpeg                     |
>> 1.2000 172872   0.7500      *                0.5500      |     
>> 0.02    0.00
>>  0.01 *           0.61 | -       -       n/a          n/a
>> MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/ 
>> mpeg2decode             |
>> 0.4500 101376   0.5500      *                0.5400      |     
>> 0.04    0.02
>>  0.03 *           0.58 | -       -       n/a          n/a
>> MultiSource/Benchmarks/sim/ 
>> sim                                           |
>> 0.0699 28828    0.1800      *                0.1800      |     
>> 5.21    5.51
>>  5.24 *           5.82 | 0.95    0.99    n/a          n/a
>> MultiSource/Benchmarks/tramp3d-v4/tramp3d- 
>> v4                             |
>> 9.2000 1943356  5.4000      *                5.1900      |    0.76 *
>>  0.64 *           6.36 | n/a     1.19    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> functionobjects                        |
>> 0.2100 37048    0.1799      *                0.1500      |     
>> 3.97    3.53
>>  3.43 *           3.66 | 1.12    1.16    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> loop_unroll                            |
>> 1.0500 328448   1.6400      *                1.7599      |     
>> 2.01    1.55
>>  1.81 *           3.63 | 1.30    1.11    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> simple_types_constant_folding          |
>> 0.8100 185728   2.1699      *                2.2599      |     
>> 1.29    1.29
>>  1.24 *           3.61 | 1.00    1.04    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> simple_types_loop_invariant            |
>> 0.6200 137560   1.1100      *                1.1199      |     
>> 3.01    3.02
>>  2.97 *           4.15 | 1.00    1.01    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> stepanov_abstraction                   |
>> 0.2900 37900    0.1700      *                0.1599      |     
>> 5.00    5.44
>>  5.26 *           5.55 | 0.92    0.95    n/a          n/a
>> SingleSource/Benchmarks/Adobe-C++/ 
>> stepanov_vector                        |
>> 0.2800 41564    0.1999      *                0.2100      |     
>> 2.93    3.09
>>  2.97 *           3.19 | 0.95    0.99    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/ 
>> fannkuch                           |
>> 0.0199 2840     0.0199      *                0.0000      |     
>> 3.45    4.30
>>  3.49 *           3.57 | 0.80    0.99    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/ 
>> fasta                              |
>> 0.0000 3000     0.0200      *                0.0200      |     
>> 1.17    1.19
>>  1.16 *           1.18 | 0.98    1.01    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/n- 
>> body                             |
>> 0.0000 3176     0.0200      *                0.0100      |     
>> 1.20    1.19
>>  1.24 *           1.23 | 1.01    0.97    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/nsieve- 
>> bits                        |
>> 0.0000 1120     0.0100      *                0.0100      |     
>> 0.99    1.02
>>  1.00 *           0.96 | 0.97    0.99    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/ 
>> partialsums                        |
>> 0.0000 1660     0.0000      *                0.0100      |     
>> 0.85    0.91
>>  0.90 *           0.83 | 0.93    0.94    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/ 
>> puzzle                             |
>> 0.0200 1276     0.0000      *                0.0100      |     
>> 0.54    0.54
>>  0.54 *           0.54 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/ 
>> recursive                          |
>> 0.0000 3444     0.0200      *                0.0200      |     
>> 1.21    0.86
>>  0.94 *           1.14 | 1.41    1.29    n/a          n/a
>> SingleSource/Benchmarks/BenchmarkGame/spectral- 
>> norm                      |
>> 0.0300 2808     0.0200      *                0.0200      |     
>> 1.37    1.41
>>  1.41 *           1.41 | 0.97    0.97    n/a          n/a
>> SingleSource/Benchmarks/CoyoteBench/ 
>> almabench                            |
>> 0.0100 5776     0.0200      *                0.0100      |    
>> 16.77    7.95
>>  8.05 *           8.12 | 2.11    2.08    n/a          n/a
>> SingleSource/Benchmarks/CoyoteBench/ 
>> fftbench                             |
>> 0.1400 22432    0.0900      *                0.0999      |    2.26 *
>>  2.21 *           2.35 | n/a     1.02    n/a          n/a
>> SingleSource/Benchmarks/CoyoteBench/ 
>> huffbench                            |
>> 0.0300 6584     0.0300      *                0.0400      |    
>> 19.18   17.21
>> 18.83 *          19.82 | 1.11    1.02    n/a          n/a
>> SingleSource/Benchmarks/CoyoteBench/ 
>> lpbench                              |
>> 0.0400 4556     0.0300      *                0.0400      |    
>> 10.94   10.91
>> 10.95 *          10.94 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Dhrystone/ 
>> dry                                    |
>> 0.0100 1300     0.0200      *                0.0000      |     
>> 3.29    0.35
>>  0.62 *           0.59 | 9.40    5.31    n/a          n/a
>> SingleSource/Benchmarks/Dhrystone/ 
>> fldry                                  |
>> 0.0099 1308     0.0100      *                0.0100      |     
>> 3.66    0.46
>>  0.58 *           0.56 | 7.96    6.31    n/a          n/a
>> SingleSource/Benchmarks/McGill/ 
>> chomp                                     |
>> 0.0400 6596     0.0600      *                0.0500      |     
>> 1.36    1.03
>>  1.00 *           1.08 | 1.32    1.36    n/a          n/a
>> SingleSource/Benchmarks/McGill/ 
>> exptree                                   |
>> 0.0300 4936     0.0300      *                0.0300      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/Benchmarks/McGill/ 
>> misr                                      |
>> 0.0200 2708     0.0200      *                0.0200      |     
>> 0.29    0.30
>>  0.28 *           0.31 | 0.97    1.04    n/a          n/a
>> SingleSource/Benchmarks/McGill/ 
>> queens                                    |
>> 0.0199 3348     0.0200      *                0.0199      |     
>> 2.39    2.40
>>  2.36 *           2.54 | 1.00    1.01    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> bigfib                                  |
>> 0.1900 40720    0.2000      *                0.1700      |    0.56 *
>>  0.56 *           0.77 | n/a     1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/mandel- 
>> text                             |
>> 0.0000 1016     0.0100      *                0.0100      |     
>> 2.26    2.26
>>  2.25 *           2.25 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> oopack_v1p8                             |
>> 0.0700 9528     0.0400      *                0.0500      |     
>> 0.17    0.18
>>  0.18 *           0.24 | 0.94    0.94    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> ray                                     |
>> 0.0800 17220    0.0700      *                0.0699      |     
>> 4.25    4.09
>>  4.16 *           4.20 | 1.04    1.02    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> sphereflake                             |
>> 0.0799 16776    0.0799      *                0.0699      |     
>> 3.09    2.79
>>  2.85 *           2.98 | 1.11    1.08    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> stepanov_container                      |
>> 0.2900 46332    0.1799      *                0.1899      |     
>> 4.29    4.40
>>  4.30 *           4.68 | 0.97    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc-C++/ 
>> stepanov_v1p2                           |
>> 0.0800 10116    0.0500      *                0.0500      |     
>> 7.87    8.27
>>  8.11 *           8.24 | 0.95    0.97    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> ReedSolomon                                 |
>> 0.0799 10636    0.0600      *                0.0499      |     
>> 7.06    7.27
>>  7.06 *           7.49 | 0.97    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> fbench                                      |
>> 0.0100 5424     0.0200      *                0.0400      |     
>> 2.30    2.23
>>  2.29 *           2.34 | 1.03    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> ffbench                                     |
>> 0.0200 4828     0.0300      *                0.0300      |     
>> 1.04    1.00
>>  1.04 *           1.08 | 1.04    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops                                       |
>> 0.0300 6552     0.0300      *                0.0300      |    
>> 12.41   12.50
>> 12.63 *          12.68 | 0.99    0.98    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-1                                     |
>> 0.0000 1152     0.0100      *                0.0100      |     
>> 2.59    2.53
>>  2.54 *           2.53 | 1.02    1.02    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-2                                     |
>> 0.0000 1252     0.0000      *                0.0200      |     
>> 1.46    1.46
>>  1.46 *           1.49 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-3                                     |
>> 0.0100 1172     0.0100      *                0.0100      |     
>> 2.63    3.13
>>  2.97 *           2.98 | 0.84    0.89    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-4                                     |
>> 0.0000 1152     0.0000      *                0.0000      |     
>> 1.23    1.37
>>  1.34 *           1.36 | 0.90    0.92    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-5                                     |
>> 0.0000 1284     0.0000      *                0.0000      |     
>> 2.15    4.37
>>  4.34 *           4.35 | 0.49    0.50    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-6                                     |
>> 0.0100 1284     0.0100      *                0.0100      |     
>> 2.23    4.94
>>  4.92 *           4.92 | 0.45    0.45    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-7                                     |
>> 0.0100 1080     0.0000      *                0.0000      |     
>> 3.91    3.79
>>  3.79 *           4.74 | 1.03    1.03    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> flops-8                                     |
>> 0.0000 1288     0.0100      *                0.0000      |     
>> 2.23    2.43
>>  2.29 *           2.30 | 0.92    0.97    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> himenobmtxpa                                |
>> 0.0600 9672     0.0500      *                0.0600      |     
>> 2.11    2.00
>>  1.99 *           2.10 | 1.05    1.06    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> mandel                                      |
>> 0.0000 1080     0.0000      *                0.0100      |     
>> 1.05    1.02
>>  1.04 *           1.41 | 1.03    1.01    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> mandel-2                                    |
>> 0.0100 1052     0.0000      *                0.0000      |     
>> 1.01    1.10
>>  1.00 *           1.00 | 0.92    1.01    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> oourafft                                    |
>> 0.1100 13740    0.0700      *                0.0699      |     
>> 8.26    7.63
>>  7.81 *           6.87 | 1.08    1.06    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> perlin                                      |
>> 0.0200 4512     0.0300      *                0.0200      |     
>> 6.64    6.67
>>  6.65 *           6.89 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> pi                                          |
>> 0.0000 1152     0.0100      *                0.0000      |     
>> 0.77    0.79
>>  0.76 *           0.84 | 0.97    1.01    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> richards_benchmark                          |
>> 0.0300 5756     0.0100      *                0.0300      |     
>> 1.13    1.05
>>  1.17 *           1.33 | 1.08    0.97    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> salsa20                                     |
>> 0.0100 2692     0.0100      *                0.0100      |     
>> 9.30    9.72
>>  9.27 *           9.33 | 0.96    1.00    n/a          n/a
>> SingleSource/Benchmarks/Misc/ 
>> whetstone                                   |
>> 0.0199 3344     0.0199      *                0.0199      |     
>> 1.63    1.52
>>  1.52 *           1.58 | 1.07    1.07    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> ackermann                           |
>> 0.0499 11044    0.0500      *                0.0400      |     
>> 1.14    1.14
>>  1.14 *           1.39 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> ary                                 |
>> 0.0300 9120     0.0299      *                0.0499      |     
>> 0.12    0.11
>>  0.11 *           0.16 | 1.09    1.09    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> ary2                                |
>> 0.0599 9784     0.0200      *                0.0500      |     
>> 0.12    0.12
>>  0.12 *           0.17 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> ary3                                |
>> 0.0599 11616    0.0599      *                0.0599      |     
>> 4.28    4.26
>>  4.30 *           4.34 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> except                              |
>> 0.0399 11292    0.0600      *                *           |    0.42 *
>>  0.41 *        *       | n/a     1.02    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> fibo                                |
>> 0.0300 7836     0.0400      *                0.0300      |     
>> 0.50    0.57
>>  0.51 *           0.63 | 0.88    0.98    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> hash                                |
>> 0.0700 15036    0.0600      *                0.1300      |     
>> 0.60    0.58
>>  0.59 *           0.78 | 1.03    1.02    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> hash2                               |
>> 0.1900 20104    0.1000      *                0.0899      |     
>> 4.53    4.35
>>  4.33 *           4.76 | 1.04    1.05    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> heapsort                            |
>> 0.0100 3012     0.0100      *                0.0199      |     
>> 4.26    4.05
>>  4.15 *           4.25 | 1.05    1.03    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> hello                               |
>> 0.0300 8304     0.0400      *                0.0300      |     
>> 0.01    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> lists                               |
>> 0.0899 11392    0.0499      *                0.0399      |     
>> 5.90    6.00
>>  5.86 *           6.10 | 0.98    1.01    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> lists1                              |
>> 0.1200 16204    0.0799      *                0.1199      |     
>> 0.33    0.34
>>  0.33 *           0.46 | 0.97    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> matrix                              |
>> 0.0400 12192    0.0600      *                0.0599      |     
>> 3.33    3.34
>>  3.35 *           3.40 | 1.00    0.99    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> methcall                            |
>> 0.0299 10800    0.0500      *                0.0299      |     
>> 5.47    5.57
>>  5.59 *           8.15 | 0.98    0.98    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> moments                             |
>> 0.0599 9084     0.0400      *                0.0300      |     
>> 0.18    0.20
>>  0.20 *           0.22 | 0.90    0.90    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> nestedloop                          |
>> 0.0499 8064     0.0400      *                0.0300      |     
>> 0.18    0.01
>>  0.18 *           0.22 | -       1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> objinst                             |
>> 0.0400 10992    0.0500      *                0.0499      |     
>> 5.73    5.80
>>  5.64 *           5.66 | 0.99    1.02    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> random                              |
>> 0.0500 7816     0.0300      *                0.0299      |     
>> 4.68    4.55
>>  4.69 *           4.59 | 1.03    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> reversefile                         |
>> 0.1500 17388    0.0600      *                0.0600      |    0.00 *
>>  0.00 *           0.07 | n/a     -       n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> sieve                               |
>> 0.0900 12556    0.0499      *                0.0499      |     
>> 2.35    2.50
>>  2.49 *           2.43 | 0.94    0.94    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> spellcheck                          |
>> 0.1600 27772    0.1200      *                0.0799      |     
>> 0.01    0.00
>>  0.00 *           0.09 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> strcat                              |
>> 0.0699 10564    0.0500      *                0.0399      |    0.15 *
>>  0.10 *           0.15 | n/a     1.50    n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> sumcol                              |
>> 0.0499 9016     0.0400      *                0.0400      |     
>> 0.00    0.01
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> wc                                  |
>> 0.0599 11144    0.0400      *                0.0500      |     
>> 0.00    0.00
>>  0.00 *           0.05 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout-C++/ 
>> wordfreq                            |
>> 0.1000 18728    0.0900      *                0.0500      |     
>> 0.00    0.00
>>  0.01 *           0.07 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> ackermann                               |
>> 0.0100 1192     0.0100      *                0.0100      |     
>> 0.02    0.01
>>  0.01 *           0.02 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> ary3                                    |
>> 0.0000 1148     0.0000      *                0.0000      |     
>> 4.40    4.32
>>  4.48 *           4.33 | 1.02    0.98    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> fib2                                    |
>> 0.0000 964      0.0200      *                0.0100      |     
>> 0.50    0.58
>>  0.51 *           0.60 | 0.86    0.98    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> hash                                    |
>> 0.0300 3028     0.0100      *                0.0100      |     
>> 3.79    3.80
>>  3.83 *           4.08 | 1.00    0.99    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> heapsort                                |
>> 0.0000 1452     0.0100      *                0.0000      |     
>> 4.10    4.09
>>  4.13 *           4.32 | 1.00    0.99    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> hello                                   |
>> 0.0000 576      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> lists                                   |
>> 0.0300 3144     0.0200      *                0.0100      |     
>> 5.85    5.77
>>  5.75 *           6.34 | 1.01    1.02    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> matrix                                  |
>> 0.0099 4128     0.0200      *                0.0100      |     
>> 3.88    3.88
>>  3.87 *           3.90 | 1.00    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> methcall                                |
>> 0.0000 1580     0.0100      *                0.0099      |     
>> 4.52    4.41
>>  4.51 *           7.02 | 1.02    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> nestedloop                              |
>> 0.0200 1128     0.0100      *                0.0100      |     
>> 0.18    0.02
>>  0.17 *           0.25 | -       1.06    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> objinst                                 |
>> 0.0100 1676     0.0100      *                0.0000      |     
>> 5.01    5.50
>>  5.17 *           5.06 | 0.91    0.97    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> random                                  |
>> 0.0000 864      0.0000      *                0.0100      |     
>> 4.55    4.52
>>  4.53 *           4.54 | 1.01    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> sieve                                   |
>> 0.0000 1288     0.0000      *                0.0100      |     
>> 6.56    5.95
>>  6.55 *           6.46 | 1.10    1.00    n/a          n/a
>> SingleSource/Benchmarks/Shootout/ 
>> strcat                                  |
>> 0.0000 1336     0.0100      *                0.0200      |     
>> 0.20    0.19
>>  0.20 *           0.22 | 1.05    1.00    n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Bubblesort                              |
>> 0.0100 1420     0.0100      *                0.0100      |     
>> 0.05    0.06
>>  0.07 *           0.07 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> IntMM                                   |
>> 0.0200 1476     0.0100      *                0.0100      |     
>> 0.01    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Oscar                                   |
>> 0.0300 3148     0.0200      *                0.0100      |     
>> 0.01    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Perm                                    |
>> 0.0000 3124     0.0200      *                0.0200      |     
>> 0.04    0.04
>>  0.04 *           0.07 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Puzzle                                  |
>> 0.0999 4820     0.0199      *                0.0300      |     
>> 0.17    0.19
>>  0.18 *           0.20 | 0.89    0.94    n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Queens                                  |
>> 0.0200 2232     0.0100      *                0.0199      |     
>> 0.05    0.05
>>  0.04 *           0.07 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Quicksort                               |
>> 0.0100 1752     0.0100      *                0.0200      |     
>> 0.05    0.05
>>  0.06 *           0.07 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> RealMM                                  |
>> 0.0100 1508     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Towers                                  |
>> 0.0200 2440     0.0200      *                0.0200      |     
>> 0.04    0.04
>>  0.03 *           0.05 | -       -       n/a          n/a
>> SingleSource/Benchmarks/Stanford/ 
>> Treesort                                |
>> 0.0100 2248     0.0200      *                0.0200      |     
>> 0.10    0.10
>>  0.08 *           0.11 | 1.00    -       n/a          n/a
>> SingleSource/Regression/C++/2003-05-14-array- 
>> init                        |
>> 0.0000 584      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-05-14- 
>> expr_stmt                         |
>> 0.0000 484      0.0000      *                0.0100      |     
>> 0.01    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-06-08- 
>> BaseType                          |
>> 0.0000 496      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-06-08- 
>> VirtualFunctions                  |
>> 0.0000 620      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-06-13- 
>> Crasher                           |
>> 0.0000 456      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-08-20- 
>> EnumSizeProblem                   |
>> 0.0000 456      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2003-09-29- 
>> NonPODsByValue                    |
>> 0.0000 576      0.0000      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/2008-01-29- 
>> ParamAliasesReturn                |
>> 0.0200 604      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> BuiltinTypeInfo                              |
>> 0.0000 728      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> ConditionalExpr                           |
>> 0.0099 712      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> ctor_dtor_count                           |
>> 0.0000 1056     0.0000      *                *           |    0.00 *
>>  0.00 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> ctor_dtor_count-2                         |
>> 0.0000 1584     0.0000      *                *           |    0.00 *
>>  0.00 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> dead_try_block                            |
>> 0.0000 568      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> exception_spec_test                       |
>> 0.0200 2472     0.0100      *                *           |    0.00 *
>>  0.01 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> function_try_block                        |
>> 0.0100 2460     0.0100      *                *           |    0.00 *
>>  0.00 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> simple_rethrow                            |
>> 0.0100 1452     0.0100      *                *           |    0.01 *
>>  0.00 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> simple_throw                              |
>> 0.0000 956      0.0000      *                *           |    0.00 *
>>  0.01 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/EH/ 
>> throw_rethrow_test                        |
>> 0.0000 1792     0.0100      *                *           |    0.00 *
>>  0.00 *        *       | n/a     -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> global_ctor                                  |
>> 0.0000 1344     0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> global_type                                  |
>> 0.0000 456      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> ofstream_ctor                                |
>> 0.0400 9176     0.0300      *                0.0300      |     
>> 0.00    0.01
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> pointer_member                               |
>> 0.0000 660      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> pointer_method                               |
>> 0.0000 664      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C++/ 
>> short_circuit_dtor                           |
>> 0.0100 644      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-14-initialize- 
>> string                   |
>> 0.0000 680      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-21- 
>> BitfieldHandling                    |
>> 0.0100 1152     0.0000      *                0.0000      |    0.00 *
>>  0.00 *           0.00 | n/a     -       n/a          n/a
>> SingleSource/Regression/C/2003-05-21- 
>> UnionBitfields                      |
>> 0.0000 580      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-21- 
>> UnionTest                           |
>> 0.0000 580      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-22- 
>> LocalTypeTest                       |
>> 0.0000 624      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-22- 
>> VarSizeArray                        |
>> 0.0000 580      0.0100      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-05-23- 
>> TransparentUnion                    |
>> 0.0000 576      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-06-16- 
>> InvalidInitializer                  |
>> 0.0000 456      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-06-16- 
>> VolatileError                       |
>> 0.0000 456      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2003-10-12- 
>> GlobalVarInitializers               |
>> 0.0000 664      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2004-02-03- 
>> AggregateCopy                       |
>> 0.0000 588      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2004-03-15- 
>> IndirectGoto                        |
>> 0.0000 860      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/Regression/C/2004-08-12- 
>> InlinerAndAllocas                   |
>> 0.0000 828      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2005-05-06- 
>> LongLongSignedShift                 |
>> 0.0000 608      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/2008-01-07- 
>> LongDouble                          |
>> 0.0000 596      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> ConstructorDestructorAttributes                |
>> 0.0000 760      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> DuffsDevice                                    |
>> 0.0000 1084     0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> PR1386                                         |
>> 0.0000 588      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> PR491                                          |
>> 0.0100 456      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> PR640                                          |
>> 0.0100 2076     0.0100      *                0.0100      |     
>> 0.01    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> badidx                                         |
>> 0.0100 1012     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> bigstack                                       |
>> 0.0000 4820     0.0200      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.03 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> callargs                                       |
>> 0.0000 928      0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> casts                                          |
>> 0.0000 3612     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.03 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> globalrefs                                     |
>> 0.0000 932      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> matrixTranspose                                |
>> 0.0100 1364     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> pointer_arithmetic                             |
>> 0.0100 488      0.0000      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> sumarray                                       |
>> 0.0100 948      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> sumarray2d                                     |
>> 0.0100 1108     0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> sumarraymalloc                                 |
>> 0.0000 1184     0.0000      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> test_indvars                                   |
>> 0.0000 1436     0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/Regression/C/ 
>> testtrace                                      |
>> 0.0100 1128     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-04-17- 
>> PrintfChar                             |
>> 0.0100 576      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> ArgumentTest                           |
>> 0.0000 624      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> CastTest                               |
>> 0.0000 1508     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> CastTest1                              |
>> 0.0100 608      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> CastTest2                              |
>> 0.0000 736      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> CastTest3                              |
>> 0.0000 684      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-02- 
>> ManyArguments                          |
>> 0.0000 696      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-03- 
>> NotTest                                |
>> 0.0000 664      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-05-19- 
>> DivTest                                |
>> 0.0100 688      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-08-02- 
>> CastTest                               |
>> 0.0000 584      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-08-02- 
>> CastTest2                              |
>> 0.0000 608      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-08-19- 
>> CodegenBug                             |
>> 0.0100 568      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-10-09- 
>> ArrayResolution                        |
>> 0.0000 644      0.0100      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-10-12- 
>> StructureArgs                          |
>> 0.0000 636      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-10-12- 
>> StructureArgsSimple                    |
>> 0.0000 604      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-10-13- 
>> BadLoad                                |
>> 0.0000 572      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2002-12-13- 
>> MishaTest                              |
>> 0.0000 584      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-04-22- 
>> Switch                                 |
>> 0.0000 736      0.0100      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-02- 
>> DependentPHI                           |
>> 0.0000 816      0.0100      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-07- 
>> VarArgs                                |
>> 0.0000 2828     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-12- 
>> MinIntProblem                          |
>> 0.0000 568      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-14- 
>> AtExit                                 |
>> 0.0000 688      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-26- 
>> Shorts                                 |
>> 0.0000 2012     0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-31- 
>> CastToBool                             |
>> 0.0100 916      0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-05-31- 
>> LongShifts                             |
>> 0.0000 952      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-07-06- 
>> IntOverflow                            |
>> 0.0200 812      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-07-08- 
>> BitOpsTest                             |
>> 0.0000 592      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-07-09- 
>> LoadShorts                             |
>> 0.0100 1520     0.0000      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-07-09- 
>> SignedArgs                             |
>> 0.0200 1676     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-07-10- 
>> SignConversions                        |
>> 0.0000 792      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-08-05- 
>> CastFPToUint                           |
>> 0.0000 720      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-08-11- 
>> VaListArg                              |
>> 0.0100 3108     0.0100      *                0.0300      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-08-20- 
>> FoldBug                                |
>> 0.0000 568      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-09-18- 
>> BitFieldTest                           |
>> 0.0000 612      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-10-13- 
>> SwitchTest                             |
>> 0.0000 652      0.0000      *                0.0000      |     
>> 0.00    0.01
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2003-10-29- 
>> ScalarReplBug                          |
>> 0.0000 580      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2004-02-02- 
>> NegativeZero                           |
>> 0.0000 640      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2004-06-20- 
>> StaticBitfieldInit                     |
>> 0.0000 684      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2004-11-28- 
>> GlobalBoolLayout                       |
>> 0.0000 880      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-05-11-Popcount-ffs- 
>> fls                       |
>> 0.0100 2144     0.0200      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-05-12- 
>> Int64ToFP                              |
>> 0.0000 684      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-05-13- 
>> SDivTwo                                |
>> 0.0000 648      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-07-15-Bitfield- 
>> ABI                           |
>> 0.0000 596      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-07-17-INT-To- 
>> FP                              |
>> 0.0100 928      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2005-11-29- 
>> LongSwitch                             |
>> 0.0100 584      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-01-23- 
>> UnionInit                              |
>> 0.0000 2152     0.0100      *                0.0100      |    0.00 *
>>  0.00 *           0.01 | n/a     -       n/a          n/a
>> SingleSource/UnitTests/2006-01-29- 
>> SimpleIndirectCall                     |
>> 0.0000 796      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-02-04- 
>> DivRem                                 |
>> 0.0100 672      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-12-01- 
>> float_varg                             |
>> 0.0000 660      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-12-04- 
>> DynAllocAndRestore                     |
>> 0.0100 480      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-12-07- 
>> Compare64BitConstant                   |
>> 0.0000 592      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2006-12-11- 
>> LoadConstants                          |
>> 0.0400 2704     0.0300      *                0.0400      |     
>> 0.00    0.00
>>  0.00 *           0.04 | -       -       n/a          n/a
>> SingleSource/UnitTests/2007-01-04-KNR- 
>> Args                               |
>> 0.0000 668      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2007-03-02- 
>> VaCopy                                 |
>> 0.0100 944      0.0100      *                0.0000      |     
>> 0.01    0.00
>>  0.01 *           0.02 | -       -       n/a          n/a
>> SingleSource/UnitTests/2007-04-10- 
>> BitfieldTest                           |
>> 0.0100 604      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2007-04-25- 
>> weak                                   |
>> 0.0000 512      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2008-04-18- 
>> LoopBug                                |
>> 0.0100 1052     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2008-04-20- 
>> LoopBug2                               |
>> 0.0000 1068     0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/2008-07-13- 
>> InlineSetjmp                           |
>> 0.0000 836      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/2009-04-16- 
>> BitfieldInitialization                 |
>> 0.0100 1900     0.0000      *                0.0000      |    0.00 *
>>  0.00 *           0.01 | n/a     -       n/a          n/a
>> SingleSource/UnitTests/ 
>> AtomicOps                                         |
>> 0.0000 812      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/ 
>> FloatPrecision                                    |
>> 0.0000 616      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> cast                                |
>> 0.0200 2548     0.0200      *                0.0300      |     
>> 0.03    0.02
>>  0.02 *           0.06 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/cast- 
>> bug                            |
>> 0.0000 632      0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> cast2                               |
>> 0.0000 592      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> ccc                                 |
>> 0.0100 772      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.01 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> div                                 |
>> 0.0000 1340     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> factor                              |
>> 0.0000 1008     0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> rem                                 |
>> 0.0400 9136     0.1100      *                0.1200      |     
>> 0.01    0.00
>>  0.00 *           0.14 | -       -       n/a          n/a
>> SingleSource/UnitTests/SignlessTypes/ 
>> shr                                 |
>> 0.0199 1448     0.0000      *                0.0000      |     
>> 0.01    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/ 
>> StructModifyTest                                  |
>> 0.0000 688      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/ 
>> TestLoop                                          |
>> 0.0000 680      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Threads/ 
>> tls                                       |
>> 0.0000 876      0.0000      *                *           |     
>> 0.00    0.01
>>  0.00 *        *       | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/SSE/ 
>> sse.expandfft                          |
>> 0.0100 6440     0.0300      *                0.0300      |     
>> 0.61    0.58
>>  0.54 *           0.60 | 1.05    1.13    n/a          n/a
>> SingleSource/UnitTests/Vector/SSE/ 
>> sse.isamax                             |
>> 0.0300 3148     0.0200      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/SSE/ 
>> sse.shift                              |
>> 0.0099 828      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/SSE/ 
>> sse.stepfft                            |
>> 0.0500 10044    0.0400      *                0.0600      |     
>> 0.63    0.62
>>  0.61 *           0.64 | 1.02    1.03    n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> build                                      |
>> 0.0000 828      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> build2                                     |
>> 0.0200 1152     0.0000      *                0.0100      |     
>> 1.95    1.96
>>  1.95 *           1.93 | 0.99    1.00    n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> divides                                    |
>> 0.0100 656      0.0000      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> multiplies                                 |
>> 0.0100 1744     0.0200      *                0.0100      |     
>> 2.80    2.81
>>  1.84 *           1.85 | 1.00    1.52    n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> simple                                     |
>> 0.0100 1216     0.0100      *                0.0100      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/ 
>> sumarray                                   |
>> 0.0100 920      0.0000      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.00 | -       -       n/a          n/a
>> SingleSource/UnitTests/Vector/sumarray- 
>> dbl                               |
>> 0.0000 976      0.0100      *                0.0100      |     
>> 0.00    0.01
>>  0.00 *           0.02 | -       -       n/a          n/a
>> SingleSource/UnitTests/ 
>> printargs                                         |
>> 0.0000 760      0.0100      *                0.0000      |     
>> 0.00    0.00
>>  0.00 *           0.01 | -       -       n/a          n/a
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
>
> -- 
> -- 
> Edward O'Callaghan
> http://www.auroraux.org/
> eocallaghan at auroraux dot org
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


From lattner at apple.com  Tue Oct 20 12:46:12 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 20 Oct 2009 10:46:12 -0700
Subject: [LLVMdev] [cfe-dev] 2.6 pre-release2 ready for testing
In-Reply-To: <ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<ee2e06e90910200424y224e068bq557ad368bf5bc4b9@mail.gmail.com>
Message-ID: <DAA140A2-6E4F-40AC-B954-EAD2A0511B55@apple.com>


On Oct 20, 2009, at 4:24 AM, Jay Foad wrote:

>> 2.6 pre-release2 is ready to be tested by the community.
>
> Excellent! Would you care to update the "LLVM 2.6 release schedule" on
> the front page of the web site?
>

Yes. But as always, its an estimate. It depends on the outcome of the  
testing.

-Tanya

> Thanks,
> Jay.


From gohman at apple.com  Tue Oct 20 12:50:40 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 20 Oct 2009 10:50:40 -0700
Subject: [LLVMdev] Target data question
In-Reply-To: <400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
	<1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>
	<400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>
Message-ID: <3F3303E5-D2D9-4CEC-950D-6E5266A44801@apple.com>


On Oct 20, 2009, at 10:13 AM, Kenneth Uildriks wrote:

> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote:
>> Unfortunately, yes.  See PR4542.  Progress has been made recently
>> though -- the optimizers are now ready.  The main things left to do
>> is to update the documentation and update the testsuite to account
>> for the change in the meaning of a module without a targetdata string.
>> 
>> Dan
>> 
>> 
> 
> So in the near future, the optimizers won't do any target-specific
> transformations in the absence of module target data?

As near as when someone steps up to do the work :-). I'm not
actively working on this myself right now.

Dan


From gohman at apple.com  Tue Oct 20 12:53:35 2009
From: gohman at apple.com (Dan Gohman)
Date: Tue, 20 Oct 2009 10:53:35 -0700
Subject: [LLVMdev] Target data question
In-Reply-To: <400d33ea0910201036r49323b7cjc67bbf7fa101a7d2@mail.gmail.com>
References: <400d33ea0910200926p209b4274wef53d6a91d3826fe@mail.gmail.com>
	<1DB87857-F0C2-4635-9FD4-0358831C04EE@apple.com>
	<400d33ea0910201013u651f95e6u82af43a60c90fed2@mail.gmail.com>
	<400d33ea0910201036r49323b7cjc67bbf7fa101a7d2@mail.gmail.com>
Message-ID: <D478E73E-25DF-46ED-9210-740BF8E9185F@apple.com>


On Oct 20, 2009, at 10:36 AM, Kenneth Uildriks wrote:

> On Tue, Oct 20, 2009 at 12:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
>> On Tue, Oct 20, 2009 at 12:08 PM, Dan Gohman <gohman at apple.com> wrote:
>>> Unfortunately, yes.  See PR4542.  Progress has been made recently
>>> though -- the optimizers are now ready.  The main things left to do
>>> is to update the documentation and update the testsuite to account
>>> for the change in the meaning of a module without a targetdata string.
>>> 
>>> Dan
>>> 
>>> 
>> 
>> So in the near future, the optimizers won't do any target-specific
>> transformations in the absence of module target data?
>> 
> 
> Also, has anyone passed a target data string to "opt" with
> -targetdata?  I'm trying that out now and getting "Too many positional
> arguments specified!".  I've tried escaping all the dashes in the
> target data string... no luck

It's broken. It's probably easily fixable if you have a good
idea of what the user interface should be.

Dan



From clattner at apple.com  Tue Oct 20 12:55:07 2009
From: clattner at apple.com (Chris Lattner)
Date: Tue, 20 Oct 2009 10:55:07 -0700
Subject: [LLVMdev] request for help writing a register allocator
In-Reply-To: <Pine.LNX.4.64.0910200919430.28605@curds.cs.wisc.edu>
References: <Pine.LNX.4.64.0910191911240.12287@curds.cs.wisc.edu>
	<E2113887-CA1A-41E8-848C-794E629196BB@apple.com>
	<728927c70910191928p2125d0d2ta1d736de0ba6ab07@mail.gmail.com>
	<66175350-505A-4DAB-9150-8BA27C42A761@apple.com>
	<Pine.LNX.4.64.0910200919430.28605@curds.cs.wisc.edu>
Message-ID: <DFA0A782-6080-4D47-B9F6-354C96096B1B@apple.com>


On Oct 20, 2009, at 7:22 AM, Susan Horwitz wrote:

> On Mon, 19 Oct 2009, Chris Lattner wrote:
>
>> Other advice: if you're looking to simplify this for students, I'd  
>> recommend staying away from X86 or ARM, which use subregs heavily.   
>> If you work with (e.g.) the sparc backend, you can avoid them  
>> completely, simplifying the problem.
>
> Chris -
>
> Thanks for your reply!  But I'm confused about the above.  In  
> particular, another reply said the following:
>
>> For each virtual register the  
>> MachineRegisterInfo::getRegClass(<vreg>) method will give you a  
>> TargetRegisterClass. You can use the allocation_order_begin/ 
>> allocation_order_end methods to iterate over the allocable physregs  
>> in that class.
>
> If I can get the appropriate physical register for each virtual one  
> this way, then how does X86's use of sub-registers complicate my  
> register-allocation code?

Each virtual register has an assigned register class.  However,  
register classes relate to each other, and the machine IR also has  
subreg references.  For example, this is how X86 handles AL/AX/EAX/RAX  
all aliasing each other.  In the Sparc backend, the only aliases are  
in the FPU, and it doesn't use subregs to model them at this point.

-Chris

From lattner at apple.com  Tue Oct 20 12:59:14 2009
From: lattner at apple.com (Tanya Lattner)
Date: Tue, 20 Oct 2009 10:59:14 -0700
Subject: [LLVMdev] 2.6 pre-release2 ready for testing
In-Reply-To: <4ADDB4D4.5010504@free.fr>
References: <9A5D25AC-5888-4BED-A917-94D4DB1BEF1A@apple.com>
	<4ADDB4D4.5010504@free.fr>
Message-ID: <81F09A6F-7488-4845-9D02-12DA0211D5CF@apple.com>


On Oct 20, 2009, at 6:02 AM, Duncan Sands wrote:

> Hi Tanya,
>
>> 1) Compile llvm from source and untar the llvm-test in the projects  
>> directory (name it llvm-test or test-suite). Choose to use a pre- 
>> compiled llvm-gcc or re-compile it yourself.
>
> I compiled llvm and llvm-gcc with separate objects directories.
> Platform is x86_64-linux-gnu.
>

Ok.


>> 2) Run make check, report any failures (FAIL or unexpected pass).  
>> Note that you need to reconfigure llvm with llvm-gcc in your path  
>> or with --with-llvmgccdir
>
> One failure:
>
> FAIL: llvm-2.6/llvm-2.6/test/Feature/load_module.ll for PR1318
> Failed with exit(1) at line 1
> while running:  llvm-as < llvm-2.6/llvm-2.6/test/Feature/ 
> load_module.ll |  opt -load=llvm-2.6/llvm-2.6-objects/Release/lib/ 
> LLVMHello.so -hello -disable-output - |& /bin/grep Hello
> Error opening 'llvm-2.6-objects/Release/lib/LLVMHello.so': llvm-2.6- 
> objects/Release/lib/LLVMHello.so: undefined symbol: _ZN4llvm4cerrE
> child process exited abnormally
>

Did you compile llvm with llvm-gcc? This is exactly PR4849.

> One unexpected pass:
>
> XPASS: llvm-2.6/llvm-2.6/test/FrontendC/2009-08-11- 
> AsmBlocksComplexJumpTarget.c
>

Does using the llvm-gcc binary for x86_64 produce the same results for  
this test?

>> 3) Run "make TEST=nightly report" and send me the report.nightly.txt
>
> Attached.
>

This seemed to be inlined into the mail instead of attached. Can you  
send again?

Thanks,
Tanya

> Ciao,
>
> Duncan.
> Program 
>                                                                   |  
> GCCAS  Bytecode LLC compile LLC-BETA compile JIT codegen | GCC      
> CBE     LLC     LLC-BETA JIT     | GCC/CBE GCC/LLC GCC/LLC-BETA LLC/ 
> LLC-BETA
> MultiSource/Applications/Burg/ 
> burg                                       | 0.4400 112068    
> 0.9899      *                1.0100      |    0.00    0.00    0.01  
> *           1.06 | -       -       n/a          n/a
> MultiSource/Applications/ClamAV/ 
> clamscan                                 | 4.7699 1321972   
> 8.1600      *                4.5900      |    0.37 *          0.21  
> *           4.98 | n/a     1.76    n/a          n/a
> MultiSource/Applications/JM/ldecod/ 
> ldecod                                | 2.6799 664468   3.1200       
> *                2.5700      |    0.12    0.11    0.12 *            
> 2.82 | 1.09    1.00    n/a          n/a
> MultiSource/Applications/JM/lencod/ 
> lencod                                | 5.6600 1462632  7.7899       
> *                6.5999      |    9.73    9.01    8.99 *           
> 16.29 | 1.08    1.08    n/a          n/a
> MultiSource/Applications/SIBsim4/ 
> SIBsim4                                 | 0.4700 88500     
> 0.5400      *                0.5399      |    4.91 *          4.55  
> *           5.41 | n/a     1.08    n/a          n/a
> MultiSource/Applications/SPASS/ 
> SPASS                                     | 6.5800 1603628   
> 6.6600      *                4.6100      |   10.54   10.00    9.98  
> *          15.63 | 1.05    1.06    n/a          n/a
> MultiSource/Applications/aha/ 
> aha                                         | 0.0499 7356      
> 0.0300      *                0.0500      |    3.23    2.97    2.78  
> *           3.26 | 1.09    1.16    n/a          n/a
> MultiSource/Applications/d/ 
> make_dparser                                  | 1.1100 311092    
> 1.1700      *                1.0100      |    0.03 *          0.03  
> *           1.14 | n/a     -       n/a          n/a
> MultiSource/Applications/hbd/ 
> hbd                                         | 0.2500 82224     
> 0.3999      *                0.3400      |    0.00    0.00    0.00  
> *           0.39 | -       -       n/a          n/a
> MultiSource/Applications/hexxagon/ 
> hexxagon                               | 0.2000 49988    0.2600       
> *                0.2399      |   12.80    9.91    9.62 *            
> 9.42 | 1.29    1.33    n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Applications/kimwitu++/ 
> kc                                    | 5.7400 1722276  8.1900       
> *                5.5100      |    0.18 *          0.14 *            
> 6.17 | n/a     1.29    n/a          n/a
> MultiSource/Applications/lambda-0.1.3/ 
> lambda                             | 0.2100 66708    0.4300       
> *                0.3199      |    5.30    5.31    5.36 *            
> 6.34 | 1.00    0.99    n/a          n/a
> MultiSource/Applications/lemon/ 
> lemon                                     | 0.4200 108608    
> 0.6300      *                0.0100      |    0.07    0.07    0.06  
> *         133.28 | -       -       n/a          n/a
> MultiSource/Applications/lua/ 
> lua                                         | 1.7100 547448    
> 2.8600      *                2.0899      |   27.89 *         27.87  
> *          30.62 | n/a     1.00    n/a          n/a
> MultiSource/Applications/minisat/ 
> minisat                                 | 0.2800 47664     
> 0.2700      *                *           |    8.31 *          8.28  
> *        *       | n/a     1.00    n/a          n/a
> MultiSource/Applications/obsequi/ 
> Obsequi                                 | 0.3600 61068     
> 0.3499      *                0.3200      |    2.55 *          2.48  
> *           3.00 | n/a     1.03    n/a          n/a
> MultiSource/Applications/oggenc/ 
> oggenc                                   | 1.5600 815432    
> 1.3699      *                1.1900      |    0.19 *          0.18  
> *           1.50 | n/a     1.06    n/a          n/a
> MultiSource/Applications/sgefa/ 
> sgefa                                     | 0.1200 17048     
> 0.1099      *                0.1199      |    0.84    0.85    0.84  
> *           1.00 | 0.99    1.00    n/a          n/a
> MultiSource/Applications/siod/ 
> siod                                       | 0.7600 344780    
> 2.4000      *                0.9599      |    3.46    3.25    3.42  
> *           4.62 | 1.06    1.01    n/a          n/a
> MultiSource/Applications/spiff/ 
> spiff                                     | 0.2000 51480     
> 0.3100      *                *           |    0.94    0.93    0.96  
> *        *       | 1.01    0.98    n/a          n/a
> MultiSource/Applications/sqlite3/ 
> sqlite3                                 | 3.6800 1139780   
> 6.3700      *                4.6300      |    5.10 *          5.15  
> *          10.40 | n/a     0.99    n/a          n/a
> MultiSource/Applications/treecc/ 
> treecc                                   | 0.7200 287712    
> 1.5700      *                0.4299      |    0.00    0.00    0.00  
> *           0.47 | -       -       n/a          n/a
> MultiSource/Applications/viterbi/ 
> viterbi                                 | 0.0499 5460      
> 0.0400      *                0.0300      |   11.62   11.68   11.81  
> *          11.87 | 0.99    0.98    n/a          n/a
> MultiSource/Benchmarks/ASCI_Purple/SMG2000/ 
> smg2000                       | 2.9899 498940   3.0500       
> *                2.2999      |    4.51    4.23    4.44 *            
> 6.71 | 1.07    1.02    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/AMGmk/ 
> AMGmk                           | 0.0999 14168    0.0800       
> *                0.0799      |   15.60   15.84   15.72 *           
> 15.78 | 0.98    0.99    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/CrystalMk/ 
> CrystalMk                   | 0.0500 8296     0.0500       
> *                0.0300      |    8.83    8.73    8.69 *            
> 8.77 | 1.01    1.02    n/a          n/a
> MultiSource/Benchmarks/ASC_Sequoia/IRSmk/ 
> IRSmk                           | 0.0100 5600     0.0300       
> *                0.0300      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/BitBench/drop3/ 
> drop3                              | 0.0200 3592     0.0199       
> *                0.0200      |    0.48    0.66    0.46 *            
> 0.49 | 0.73    1.04    n/a          n/a
> MultiSource/Benchmarks/BitBench/five11/ 
> five11                            | 0.0000 2768     0.0100       
> *                0.0100      |    2.33    2.44    2.27 *            
> 2.39 | 0.95    1.03    n/a          n/a
> MultiSource/Benchmarks/BitBench/uudecode/ 
> uudecode                        | 0.0200 2968     0.0100       
> *                0.0000      |    0.13    0.12    0.14 *            
> 0.14 | 1.08    0.93    n/a          n/a
> MultiSource/Benchmarks/BitBench/uuencode/ 
> uuencode                        | 0.0200 2764     0.0200       
> *                0.0100      |    0.00    0.01    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Fhourstones-3.1/ 
> fhourstones3.1                    | 0.0500 8160     0.0500       
> *                0.0500      |    1.63    1.70    1.58 *            
> 1.64 | 0.96    1.03    n/a          n/a
> MultiSource/Benchmarks/Fhourstones/ 
> fhourstones                           | 0.0699 11088    0.0600       
> *                0.0500      |    1.42    1.32    1.33 *            
> 1.39 | 1.08    1.07    n/a          n/a
> MultiSource/Benchmarks/FreeBench/analyzer/ 
> analyzer                       | 0.0600 10052    0.0600       
> *                0.0600      |    0.14    0.14    0.12 *            
> 0.18 | 1.00    1.17    n/a          n/a
> MultiSource/Benchmarks/FreeBench/distray/ 
> distray                         | 0.0200 6952     0.0300       
> *                0.0300      |    0.16    0.17    0.18 *            
> 0.23 | 0.94    0.89    n/a          n/a
> MultiSource/Benchmarks/FreeBench/fourinarow/ 
> fourinarow                   | 0.1099 18888    0.1199       
> *                0.0900      |    0.36    0.35    0.37 *            
> 0.47 | 1.03    0.97    n/a          n/a
> MultiSource/Benchmarks/FreeBench/mason/ 
> mason                             | 0.0300 6148     0.0200       
> *                0.0300      |    0.23    0.26    0.25 *            
> 0.29 | 0.88    0.92    n/a          n/a
> MultiSource/Benchmarks/FreeBench/neural/ 
> neural                           | 0.0700 9712     0.0500       
> *                0.0699      |    0.24    0.27    0.23 *            
> 0.34 | 0.89    1.04    n/a          n/a
> MultiSource/Benchmarks/FreeBench/pcompress2/ 
> pcompress2                   | 0.0599 11084    0.0500       
> *                0.0600      |    0.23    0.21    0.21 *            
> 0.29 | 1.10    1.10    n/a          n/a
> MultiSource/Benchmarks/FreeBench/pifft/ 
> pifft                             | 0.2900 60776    0.3400       
> *                0.3300      |    0.14    0.14    0.14 *            
> 0.50 | 1.00    1.00    n/a          n/a
> MultiSource/Benchmarks/MallocBench/cfrac/ 
> cfrac                           | 0.2100 92260    0.3600       
> *                0.3500      |    1.44    1.44    1.38 *            
> 1.80 | 1.00    1.04    n/a          n/a
> MultiSource/Benchmarks/MallocBench/espresso/ 
> espresso                     | 1.4700 414748   2.4299       
> *                1.6400      |    0.61    0.55    0.54 *            
> 2.27 | 1.11    1.13    n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MallocBench/gs/ 
> gs                                 | 1.2000 376224   1.7600       
> *                0.7900      |    0.07 *          0.06 *            
> 0.95 | n/a     -       n/a          n/a
> MultiSource/Benchmarks/McCat/01-qbsort/ 
> qbsort                            | 0.0099 3600     0.0200       
> *                0.0300      |    0.07    0.06    0.05 *            
> 0.10 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/03-testtrie/ 
> testtrie                        | 0.0200 3756     0.0100       
> *                0.0300      |    0.02    0.01    0.01 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/04-bisect/ 
> bisect                            | 0.0300 4036     0.0400       
> *                0.0199      |    0.14    0.13    0.13 *            
> 0.17 | 1.08    1.08    n/a          n/a
> MultiSource/Benchmarks/McCat/05-eks/ 
> eks                                  | 0.0999 7888     0.0500       
> *                0.0500      |    0.01    0.00    0.02 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/08-main/ 
> main                                | 0.0900 11928    0.0500       
> *                0.0599      |    0.07    0.03    0.03 *            
> 0.09 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/09-vor/ 
> vor                                  | 0.0999 23148    0.1300       
> *                0.1200      |    0.15    0.12    0.11 *            
> 0.25 | 1.25    1.36    n/a          n/a
> MultiSource/Benchmarks/McCat/12-IOtest/ 
> iotest                            | 0.0199 2176     0.0100       
> *                0.0200      |    0.33    0.23    0.20 *            
> 0.23 | 1.43    1.65    n/a          n/a
> MultiSource/Benchmarks/McCat/15-trie/ 
> trie                                | 0.0100 3216     0.0300       
> *                0.0300      |    0.00    0.00    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/McCat/17-bintr/ 
> bintr                              | 0.0199 3676     0.0199       
> *                0.0300      |    0.11    0.10    0.11 *            
> 0.13 | 1.10    1.00    n/a          n/a
> MultiSource/Benchmarks/McCat/18-imp/ 
> imp                                  | 0.0999 21512    0.1099       
> *                0.1200      |    0.07 *          0.08 *            
> 0.20 | n/a     -       n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/automotive-basicmath/automotive- 
> basicmath | 0.0200 4816     0.0300      *                0.0400       
> |    0.40    0.39    0.39 *           0.44 | 1.03    1.03    n/ 
> a          n/a
> MultiSource/Benchmarks/MiBench/automotive-bitcount/automotive- 
> bitcount   | 0.0300 3540     0.0200      *                 
> 0.0399      |    0.13    0.13    0.15 *           0.19 | 1.00     
> 0.87    n/a          n/a
> MultiSource/Benchmarks/MiBench/automotive-susan/automotive- 
> susan         | 0.2500 64756    0.3100      *                 
> 0.3200      |    0.07    0.06    0.05 *           0.38 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/consumer-jpeg/consumer- 
> jpeg               | 1.2500 205708   0.9300      *                 
> 0.4900      |    0.02    0.01    0.01 *           0.54 | -        
> -       n/a          n/a
> 			llc: /home/duncan/tmp/tmp/llvm-2.6/llvm-2.6/lib/Target/CBackend/ 
> CBackend.cpp:488:  
> llvm::raw_ostream&<unnamed>::CWriter::printSimpleType 
> (llvm::formatted_raw_ostream&, const llvm::Type*, bool, const  
> std::string&): Assertion `NumBits <= 128 && "Bit widths > 128 not  
> implemented yet"' failed.
> MultiSource/Benchmarks/MiBench/consumer-lame/consumer- 
> lame               | 1.3200 335108   1.3200      *                 
> 1.2100      |    0.28 *          0.27 *           1.58 | n/a      
> 1.04    n/a          n/a
> MultiSource/Benchmarks/MiBench/consumer-typeset/consumer- 
> typeset         | 5.7999 1397316  6.9899      *                 
> 6.0300      |    0.35 *          0.22 *           6.47 | n/a      
> 1.59    n/a          n/a
> MultiSource/Benchmarks/MiBench/network-dijkstra/network- 
> dijkstra         | 0.0100 3512     0.0300      *                 
> 0.0200      |    0.04    0.05    0.05 *           0.07 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/network-patricia/network- 
> patricia         | 0.0300 4248     0.0300      *                 
> 0.0200      |    0.14    0.12    0.12 *           0.16 | 1.17     
> 1.17    n/a          n/a
> MultiSource/Benchmarks/MiBench/office-ispell/office- 
> ispell               | 0.5400 128620   0.7899      *                 
> 0.2400      |    0.01    0.00    0.00 *           0.26 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/office-stringsearch/office- 
> stringsearch   | 0.0200 13232    0.0199      *                 
> 0.0300      |    0.00    0.01    0.00 *           0.03 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-blowfish/security- 
> blowfish       | 0.0999 30936    0.1099      *                 
> 0.0600      |    0.01    0.00    0.00 *           0.07 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-rijndael/security- 
> rijndael       | 0.1400 51232    0.1000      *                 
> 0.0700      |    0.08    0.06    0.07 *           0.16 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/security-sha/security- 
> sha                 | 0.0300 4760     0.0300      *                 
> 0.0300      |    0.07    0.03    0.03 *           0.05 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm- 
> CRC32             | 0.0000 3180     0.0100      *                 
> 0.0000      |    0.41    0.28    0.28 *           0.30 | 1.46     
> 1.46    n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-FFT/telecomm- 
> fft                 | 0.0200 4880     0.0300      *                 
> 0.0199      |    0.06    0.07    0.06 *           0.09 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-adpcm/telecomm- 
> adpcm             | 0.0000 2196     0.0100      *                 
> 0.0100      |    0.01    0.00    0.00 *           0.02 | -        
> -       n/a          n/a
> MultiSource/Benchmarks/MiBench/telecomm-gsm/telecomm- 
> gsm                 | 0.3500 76716    0.3299      *                 
> 0.1900      |    0.23    0.24    0.23 *           0.43 | 0.96     
> 1.00    n/a          n/a
> MultiSource/Benchmarks/NPB-serial/is/ 
> is                                  | 0.0099 5116     0.0300       
> *                0.3599      |   10.08    9.85    9.84 *           
> 10.18 | 1.02    1.02    n/a          n/a
> MultiSource/Benchmarks/Olden/bh/ 
> bh                                       | 0.1199 15308     
> 0.0800      *                0.0699      |    1.97 *          1.57  
> *           1.67 | n/a     1.25    n/a          n/a
> MultiSource/Benchmarks/Olden/bisort/ 
> bisort                               | 0.0100 3688     0.0199       
> *                0.0200      |    0.80    0.82    0.79 *            
> 0.81 | 0.98    1.01    n/a          n/a
> MultiSource/Benchmarks/Olden/em3d/ 
> em3d                                   | 0.0400 6412     0.0400       
> *                0.0499      |    3.30    3.29    3.29 *            
> 3.32 | 1.00    1.00    n/a          n/a
> MultiSource/Benchmarks/Olden/health/ 
> health                               | 0.0300 7608     0.0400       
> *                0.0300      |    0.52 *          0.50 *            
> 0.54 | n/a     1.04    n/a          n/a
> MultiSource/Benchmarks/Olden/mst/ 
> mst                                     | 0.0500 4176      
> 0.0300      *                0.0300      |    0.15    0.14    0.14  
> *           0.18 | 1.07    1.07    n/a          n/a
> MultiSource/Benchmarks/Olden/perimeter/ 
> perimeter                         | 0.0000 12340    0.0799       
> *                0.0699      |    0.36    0.34    0.32 *            
> 0.38 | 1.06    1.12    n/a          n/a
> MultiSource/Benchmarks/Olden/power/ 
> power                                 | 0.0200 8564     0.0300       
> *                0.0300      |    1.56    1.55    1.52 *            
> 1.57 | 1.01    1.03    n/a          n/a
> MultiSource/Benchmarks/Olden/treeadd/ 
> treeadd                             | 0.0100 1824     0.0200       
> *                0.0200      |    0.33    0.34    0.34 *            
> 0.34 | 0.97    0.97    n/a          n/a
> MultiSource/Benchmarks/Olden/tsp/ 
> tsp                                     | 0.0300 6988      
> 0.0300      *                0.0200      |    1.15    1.13    1.14  
> *           1.16 | 1.02    1.01    n/a          n/a
> MultiSource/Benchmarks/Olden/voronoi/ 
> voronoi                             | 0.0900 13436    0.0500       
> *                0.0400      |    0.42    0.41    0.42 *            
> 0.48 | 1.02    1.00    n/a          n/a
> MultiSource/Benchmarks/OptimizerEval/optimizer- 
> eval                      | 0.0800 29224    0.1500       
> *                0.1800      |  106.85  110.58  109.30 *           
> 96.14 | 0.97    0.98    n/a          n/a
> MultiSource/Benchmarks/PAQ8p/ 
> paq8p                                       | 0.9300 198188    
> 1.0400      *                *           |    0.00 *          0.01  
> *        *       | n/a     -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/NP/ 
> np                                | 0.0000 1188     0.0000       
> *                0.0000      |    0.00    0.00    0.00 *            
> 0.01 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/city/ 
> city                            | 0.1199 23708    0.0800       
> *                0.0699      |    0.01    0.01    0.00 *            
> 0.09 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv1/ 
> deriv1                        | 0.0600 12928    0.0500       
> *                0.0600      |    0.01    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/deriv2/ 
> deriv2                        | 0.0400 14480    0.0700       
> *                0.0499      |    0.00    0.00    0.00 *            
> 0.07 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/employ/ 
> employ                        | 0.1000 21900    0.1099       
> *                0.0799      |    0.02    0.01    0.01 *            
> 0.10 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/family/ 
> family                        | 0.0300 3388     0.0200       
> *                0.0199      |    0.00    0.01    0.00 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/fsm/ 
> fsm                              | 0.0100 1904     0.0100       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/garage/ 
> garage                        | 0.0499 7428     0.0400       
> *                0.0400      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/life/ 
> life                            | 0.0200 6324     0.0300       
> *                0.0100      |    1.38    1.44    1.45 *            
> 1.48 | 0.96    0.95    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/objects/ 
> objects                      | 0.0300 9980     0.0500       
> *                0.0200      |    0.00    0.01    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/ocean/ 
> ocean                          | 0.0200 8880     0.0500       
> *                0.0399      |    0.12    0.11    0.12 *            
> 0.16 | 1.09    1.00    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/office/ 
> office                        | 0.0400 12924    0.0699       
> *                0.0500      |    0.00    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/primes/ 
> primes                        | 0.0100 1584     0.0100       
> *                0.0100      |    0.37    0.35    0.35 *            
> 0.37 | 1.06    1.06    n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/shapes/ 
> shapes                        | 0.0399 16268    0.0899       
> *                0.0699      |    0.01    0.01    0.01 *            
> 0.08 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/simul/ 
> simul                          | 0.0600 4176     0.0200       
> *                0.0100      |    0.01    0.01    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/trees/ 
> trees                          | 0.0500 11288    0.0700       
> *                0.0500      |    0.00    0.01    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C++/vcirc/ 
> vcirc                          | 0.0100 1768     0.0000       
> *                0.0000      |    0.01    0.00    0.01 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/TimberWolfMC/ 
> timberwolfmc              | 1.7300 563480   3.2999       
> *                0.5900      |    0.01    0.00    0.00 *            
> 0.63 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/agrep/ 
> agrep                            | 0.3700 92964    0.5300       
> *                0.1999      |    0.02    0.01    0.01 *            
> 0.23 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/allroots/ 
> allroots                      | 0.0200 3556     0.0200       
> *                0.0200      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/archie-client/ 
> archie                   | 0.2000 47648    0.2199       
> *                0.0600      |    0.01 *          0.00 *            
> 0.07 | n/a     -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/assembler/ 
> assembler                    | 0.1600 61544    0.3900       
> *                0.2999      |    0.00    0.00    0.00 *            
> 0.33 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/bison/ 
> mybison                          | 0.3600 112424   0.9900       
> *                0.9100      |    0.00    0.00    0.00 *            
> 0.95 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/cdecl/ 
> cdecl                            | 0.0999 48484    0.3199       
> *                0.3400      |    0.01    0.00    0.00 *            
> 0.35 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/compiler/ 
> compiler                      | 0.1100 36440    0.2900       
> *                0.0500      |    0.00    0.00    0.00 *            
> 0.06 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/fixoutput/ 
> fixoutput                    | 0.0100 6044     0.0400       
> *                0.0200      |    0.00    0.00    0.00 *            
> 0.04 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/football/ 
> football                      | 0.3500 85712    0.5500       
> *                0.0400      |    0.00    0.00    0.01 *            
> 0.05 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/gnugo/ 
> gnugo                            | 0.1400 35692    0.2100       
> *                0.2200      |    0.07    0.07    0.07 *            
> 0.30 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/loader/ 
> loader                          | 0.0899 28276    0.1400       
> *                0.1199      |    0.00    0.00    0.00 *            
> 0.14 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/plot2fig/ 
> plot2fig                      | 0.0500 14756    0.0900       
> *                0.0999      |    0.00    0.00    0.01 *            
> 0.11 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/simulator/ 
> simulator                    | 0.2600 64712    0.4000       
> *                0.0500      |    0.00    0.01    0.00 *            
> 0.07 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/unix-smail/unix- 
> smail                  | 0.1100 39652    0.3000       
> *                0.2000      |    0.00    0.01    0.00 *            
> 0.22 | -       -       n/a          n/a
> MultiSource/Benchmarks/Prolangs-C/unix-tbl/unix- 
> tbl                      | 0.3000 78708    0.4900       
> *                0.0200      |    0.00    0.00    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/Ptrdist/anagram/ 
> anagram                           | 0.0500 7764     0.0500       
> *                0.0300      |    1.46    0.97    1.38 *            
> 1.36 | 1.51    1.06    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/bc/ 
> bc                                     | 0.3300 126012   0.7700       
> *                0.7100      |    0.66    0.68    0.64 *            
> 1.41 | 0.97    1.03    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/ft/ 
> ft                                     | 0.0600 7236     0.0500       
> *                0.0400      |    1.17    1.22    1.27 *            
> 1.28 | 0.96    0.92    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/ks/ 
> ks                                     | 0.0299 11912    0.0699       
> *                0.0700      |    2.23    1.44    2.26 *            
> 2.21 | 1.55    0.99    n/a          n/a
> MultiSource/Benchmarks/Ptrdist/yacr2/ 
> yacr2                               | 0.2200 48228    0.3600       
> *                0.3100      |    1.23    1.10    1.22 *            
> 1.56 | 1.12    1.01    n/a          n/a
> MultiSource/Benchmarks/SciMark2-C/ 
> scimark2                               | 0.1099 15340    0.0799       
> *                0.0999      |   27.62 *         27.38 *           
> 27.87 | n/a     1.01    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-3des/ 
> enc-3des                        | 0.1599 21456    0.1000       
> *                0.1200      |    2.23    2.10    2.14 *            
> 2.31 | 1.06    1.04    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-md5/enc- 
> md5                          | 0.0599 7692     0.0400       
> *                0.0400      |    2.16    2.04    2.05 *            
> 2.21 | 1.06    1.05    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-pc1/enc- 
> pc1                          | 0.0300 3964     0.0199       
> *                0.0300      |    1.39    0.97    0.92 *            
> 0.95 | 1.43    1.51    n/a          n/a
> MultiSource/Benchmarks/Trimaran/enc-rc4/enc- 
> rc4                          | 0.0000 2960     0.0100       
> *                0.0100      |    1.18    1.20    1.16 *            
> 1.24 | 0.98    1.02    n/a          n/a
> MultiSource/Benchmarks/Trimaran/netbench-crc/netbench- 
> crc                | 0.0000 32680    0.0100      *                 
> 0.0100      |    1.01    1.00    1.09 *           1.07 | 1.01     
> 0.93    n/a          n/a
> MultiSource/Benchmarks/Trimaran/netbench-url/netbench- 
> url                | 0.0400 40832    0.0500      *                 
> 0.0400      |    3.89    3.45    3.88 *           3.94 | 1.13     
> 1.00    n/a          n/a
> MultiSource/Benchmarks/VersaBench/8b10b/ 
> 8b10b                            | 0.0000 2240     0.0100       
> *                0.0100      |    7.07    4.94    4.99 *            
> 4.97 | 1.43    1.42    n/a          n/a
> MultiSource/Benchmarks/VersaBench/beamformer/ 
> beamformer                  | 0.0400 5764     0.0300       
> *                0.0300      |    1.85    1.92    1.76 *            
> 1.80 | 0.96    1.05    n/a          n/a
> MultiSource/Benchmarks/VersaBench/bmm/ 
> bmm                                | 0.0199 2896     0.0100       
> *                0.0300      |    2.34    2.35    2.36 *            
> 2.39 | 1.00    0.99    n/a          n/a
> MultiSource/Benchmarks/VersaBench/dbms/ 
> dbms                              | 0.1200 36468    0.2500       
> *                0.2400      |    2.34    2.23    2.17 *            
> 2.35 | 1.05    1.08    n/a          n/a
> MultiSource/Benchmarks/VersaBench/ecbdes/ 
> ecbdes                          | 0.0599 9740     0.0200       
> *                0.0200      |    2.87    2.91    2.77 *            
> 2.76 | 0.99    1.04    n/a          n/a
> MultiSource/Benchmarks/llubenchmark/ 
> llu                                  | 0.0000 3896     0.0300       
> *                0.0300      |    6.10    6.30    6.24 *            
> 6.31 | 0.97    0.98    n/a          n/a
> MultiSource/Benchmarks/mafft/ 
> pairlocalalign                              | 3.7200 346176    
> 1.9100      *                *           |    0.00    0.00    0.00  
> *           0.00 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawcaudio/ 
> rawcaudio              | 0.0100 2324     0.0100       
> *                0.0100      |    0.00    0.01    0.01 *            
> 0.03 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/adpcm/rawdaudio/ 
> rawdaudio              | 0.0100 2196     0.0000       
> *                0.0100      |    0.00    0.00    0.00 *            
> 0.02 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/g721/g721encode/ 
> encode                 | 0.0600 13104    0.0800       
> *                0.0600      |    0.09    0.09    0.08 *            
> 0.14 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/gsm/toast/ 
> toast                        | 0.3800 76716    0.2700       
> *                0.2099      |    0.06    0.04    0.03 *            
> 0.24 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/jpeg/jpeg-6a/ 
> cjpeg                     | 1.2000 172872   0.7500       
> *                0.5500      |    0.02    0.00    0.01 *            
> 0.61 | -       -       n/a          n/a
> MultiSource/Benchmarks/mediabench/mpeg2/mpeg2dec/ 
> mpeg2decode             | 0.4500 101376   0.5500       
> *                0.5400      |    0.04    0.02    0.03 *            
> 0.58 | -       -       n/a          n/a
> MultiSource/Benchmarks/sim/ 
> sim                                           | 0.0699 28828     
> 0.1800      *                0.1800      |    5.21    5.51    5.24  
> *           5.82 | 0.95    0.99    n/a          n/a
> MultiSource/Benchmarks/tramp3d-v4/tramp3d- 
> v4                             | 9.2000 1943356  5.4000       
> *                5.1900      |    0.76 *          0.64 *            
> 6.36 | n/a     1.19    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> functionobjects                        | 0.2100 37048    0.1799       
> *                0.1500      |    3.97    3.53    3.43 *            
> 3.66 | 1.12    1.16    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> loop_unroll                            | 1.0500 328448   1.6400       
> *                1.7599      |    2.01    1.55    1.81 *            
> 3.63 | 1.30    1.11    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> simple_types_constant_folding          | 0.8100 185728   2.1699       
> *                2.2599      |    1.29    1.29    1.24 *            
> 3.61 | 1.00    1.04    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> simple_types_loop_invariant            | 0.6200 137560   1.1100       
> *                1.1199      |    3.01    3.02    2.97 *            
> 4.15 | 1.00    1.01    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> stepanov_abstraction                   | 0.2900 37900    0.1700       
> *                0.1599      |    5.00    5.44    5.26 *            
> 5.55 | 0.92    0.95    n/a          n/a
> SingleSource/Benchmarks/Adobe-C++/ 
> stepanov_vector                        | 0.2800 41564    0.1999       
> *                0.2100      |    2.93    3.09    2.97 *            
> 3.19 | 0.95    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> fannkuch                           | 0.0199 2840     0.0199       
> *                0.0000      |    3.45    4.30    3.49 *            
> 3.57 | 0.80    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> fasta                              | 0.0000 3000     0.0200       
> *                0.0200      |    1.17    1.19    1.16 *            
> 1.18 | 0.98    1.01    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/n- 
> body                             | 0.0000 3176     0.0200       
> *                0.0100      |    1.20    1.19    1.24 *            
> 1.23 | 1.01    0.97    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/nsieve- 
> bits                        | 0.0000 1120     0.0100       
> *                0.0100      |    0.99    1.02    1.00 *            
> 0.96 | 0.97    0.99    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> partialsums                        | 0.0000 1660     0.0000       
> *                0.0100      |    0.85    0.91    0.90 *            
> 0.83 | 0.93    0.94    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> puzzle                             | 0.0200 1276     0.0000       
> *                0.0100      |    0.54    0.54    0.54 *            
> 0.54 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/ 
> recursive                          | 0.0000 3444     0.0200       
> *                0.0200      |    1.21    0.86    0.94 *            
> 1.14 | 1.41    1.29    n/a          n/a
> SingleSource/Benchmarks/BenchmarkGame/spectral- 
> norm                      | 0.0300 2808     0.0200       
> *                0.0200      |    1.37    1.41    1.41 *            
> 1.41 | 0.97    0.97    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> almabench                            | 0.0100 5776     0.0200       
> *                0.0100      |   16.77    7.95    8.05 *            
> 8.12 | 2.11    2.08    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> fftbench                             | 0.1400 22432    0.0900       
> *                0.0999      |    2.26 *          2.21 *            
> 2.35 | n/a     1.02    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> huffbench                            | 0.0300 6584     0.0300       
> *                0.0400      |   19.18   17.21   18.83 *           
> 19.82 | 1.11    1.02    n/a          n/a
> SingleSource/Benchmarks/CoyoteBench/ 
> lpbench                              | 0.0400 4556     0.0300       
> *                0.0400      |   10.94   10.91   10.95 *           
> 10.94 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Dhrystone/ 
> dry                                    | 0.0100 1300     0.0200       
> *                0.0000      |    3.29    0.35    0.62 *            
> 0.59 | 9.40    5.31    n/a          n/a
> SingleSource/Benchmarks/Dhrystone/ 
> fldry                                  | 0.0099 1308     0.0100       
> *                0.0100      |    3.66    0.46    0.58 *            
> 0.56 | 7.96    6.31    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> chomp                                     | 0.0400 6596      
> 0.0600      *                0.0500      |    1.36    1.03    1.00  
> *           1.08 | 1.32    1.36    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> exptree                                   | 0.0300 4936      
> 0.0300      *                0.0300      |    0.00    0.00    0.00  
> *           0.04 | -       -       n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> misr                                      | 0.0200 2708      
> 0.0200      *                0.0200      |    0.29    0.30    0.28  
> *           0.31 | 0.97    1.04    n/a          n/a
> SingleSource/Benchmarks/McGill/ 
> queens                                    | 0.0199 3348      
> 0.0200      *                0.0199      |    2.39    2.40    2.36  
> *           2.54 | 1.00    1.01    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> bigfib                                  | 0.1900 40720     
> 0.2000      *                0.1700      |    0.56 *          0.56  
> *           0.77 | n/a     1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/mandel- 
> text                             | 0.0000 1016     0.0100       
> *                0.0100      |    2.26    2.26    2.25 *            
> 2.25 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> oopack_v1p8                             | 0.0700 9528      
> 0.0400      *                0.0500      |    0.17    0.18    0.18  
> *           0.24 | 0.94    0.94    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> ray                                     | 0.0800 17220     
> 0.0700      *                0.0699      |    4.25    4.09    4.16  
> *           4.20 | 1.04    1.02    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> sphereflake                             | 0.0799 16776     
> 0.0799      *                0.0699      |    3.09    2.79    2.85  
> *           2.98 | 1.11    1.08    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> stepanov_container                      | 0.2900 46332     
> 0.1799      *                0.1899      |    4.29    4.40    4.30  
> *           4.68 | 0.97    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc-C++/ 
> stepanov_v1p2                           | 0.0800 10116     
> 0.0500      *                0.0500      |    7.87    8.27    8.11  
> *           8.24 | 0.95    0.97    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> ReedSolomon                                 | 0.0799 10636     
> 0.0600      *                0.0499      |    7.06    7.27    7.06  
> *           7.49 | 0.97    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> fbench                                      | 0.0100 5424      
> 0.0200      *                0.0400      |    2.30    2.23    2.29  
> *           2.34 | 1.03    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> ffbench                                     | 0.0200 4828      
> 0.0300      *                0.0300      |    1.04    1.00    1.04  
> *           1.08 | 1.04    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops                                       | 0.0300 6552      
> 0.0300      *                0.0300      |   12.41   12.50   12.63  
> *          12.68 | 0.99    0.98    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-1                                     | 0.0000 1152      
> 0.0100      *                0.0100      |    2.59    2.53    2.54  
> *           2.53 | 1.02    1.02    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-2                                     | 0.0000 1252      
> 0.0000      *                0.0200      |    1.46    1.46    1.46  
> *           1.49 | 1.00    1.00    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-3                                     | 0.0100 1172      
> 0.0100      *                0.0100      |    2.63    3.13    2.97  
> *           2.98 | 0.84    0.89    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-4                                     | 0.0000 1152      
> 0.0000      *                0.0000      |    1.23    1.37    1.34  
> *           1.36 | 0.90    0.92    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-5                                     | 0.0000 1284      
> 0.0000      *                0.0000      |    2.15    4.37    4.34  
> *           4.35 | 0.49    0.50    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-6                                     | 0.0100 1284      
> 0.0100      *                0.0100      |    2.23    4.94    4.92  
> *           4.92 | 0.45    0.45    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-7                                     | 0.0100 1080      
> 0.0000      *                0.0000      |    3.91    3.79    3.79  
> *           4.74 | 1.03    1.03    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> flops-8                                     | 0.0000 1288      
> 0.0100      *                0.0000      |    2.23    2.43    2.29  
> *           2.30 | 0.92    0.97    n/a          n/a
> SingleSource/Benchmarks/Misc/ 
> himenobmtxpa                                | 0.0600 9672      
> 0.0500      *