From xerxes at zafena.se  Tue Oct  6 07:22:56 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Tue, 06 Oct 2009 16:22:56 +0200
Subject: [patch] rfc: shark overloaded intrinsic suffix fix
Message-ID: <4ACB52C0.10609@zafena.se>

I was toying with adding some optimization passes and verify passes to
speed up and more runtime checks to shark, while doing so then one of
the verify passes found at least one oddity in the shark sourcecode.
The attached patch fixes this verifier issue.

verifier output:
Overloaded intrinsic has incorrect suffix: '.i32'. It should be '.i32.p0i32'
i32 (i32*, i32, i32)* @llvm.atomic.cmp.swap.i32
Broken module found, compilation aborted!
Stack dump:
0.    Running pass 'Module Verifier' on function
'@"java.io.BufferedReader::readLine"'
Avbruten (SIGABRT)

http://llvm.org/docs/LangRef.html#int_atomics

Ok to push?

Cheers
Xerxes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_verifier.patch
Type: text/x-patch
Size: 787 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091006/046d34b0/attachment.bin 

From gbenson at redhat.com  Mon Oct 12 04:11:59 2009
From: gbenson at redhat.com (Gary Benson)
Date: Mon, 12 Oct 2009 12:11:59 +0100
Subject: Shark tweak
Message-ID: <20091012111159.GA3601@redhat.com>

Hi all,

This commit removes a bunch of debug options from Shark that duplicate
functionality already in HotSpot.  If you were using the Shark options
then please switch to their HotSpot equivalents:

  SharkStartAt -- use CIStart or CIStartOSR
  SharkStopAfter -- use CIEnd or CIEndOSR
  SharkOnlyCompile -- use CompileOnly

Cheers,
Gary

-- 
http://gbenson.net/
-------------- next part --------------
diff -r d1d6d20cf4d1 ChangeLog
--- a/ChangeLog	Mon Oct 12 11:50:57 2009 +0100
+++ b/ChangeLog	Mon Oct 12 12:01:20 2009 +0100
@@ -1,3 +1,10 @@
+2009-10-12  Gary Benson  <gbenson at redhat.com>
+
+	* ports/hotspot/src/share/vm/shark/shark_globals.hpp:
+	Removed SharkStartAt, SharkStopAfter and SharkOnlyCompile.
+	* ports/hotspot/src/share/vm/shark/shark_globals.hpp
+	(SharkCompiler::compile_method): Likewise.
+
 2009-10-09  Edward Nevill   <ed at camswl.com>
 
 	* Added initial support for Shark + ARM asm
diff -r d1d6d20cf4d1 ports/hotspot/src/share/vm/shark/sharkCompiler.cpp
--- a/ports/hotspot/src/share/vm/shark/sharkCompiler.cpp	Mon Oct 12 11:50:57 2009 +0100
+++ b/ports/hotspot/src/share/vm/shark/sharkCompiler.cpp	Mon Oct 12 12:01:20 2009 +0100
@@ -94,27 +94,6 @@
   ResourceMark rm;
   const char *name = methodname(target);
 
-#ifndef PRODUCT
-  // Skip methods if requested
-  static uintx methods_seen = 0;
-  methods_seen++;
-  if (methods_seen < SharkStartAt) {
-    env->record_method_not_compilable("methods_seen < SharkStartAt");
-    return;
-  }
-  else if (methods_seen > SharkStopAfter) {
-    while (true)
-      sleep(1);
-  }
-#endif // !PRODUCT
-
-  if (SharkOnlyCompile != NULL) {
-    if (fnmatch(SharkOnlyCompile, name, 0)) {
-      env->record_method_not_compilable("does not match SharkOnlyCompile");
-      return;
-    }
-  }
-
   // Do the typeflow analysis
   ciTypeFlow *flow;
   if (entry_bci == InvocationEntryBci)
diff -r d1d6d20cf4d1 ports/hotspot/src/share/vm/shark/shark_globals.hpp
--- a/ports/hotspot/src/share/vm/shark/shark_globals.hpp	Mon Oct 12 11:50:57 2009 +0100
+++ b/ports/hotspot/src/share/vm/shark/shark_globals.hpp	Mon Oct 12 12:01:20 2009 +0100
@@ -37,15 +37,6 @@
           "Maximum bytecode size of methods to inline when using Shark")      \
                                                                               \
   /* compiler debugging */                                                    \
-  develop(uintx, SharkStartAt, 0,                                             \
-          "First method to consider when using Shark")                        \
-                                                                              \
-  develop(uintx, SharkStopAfter, max_uintx,                                   \
-          "Last method to consider when using Shark")                         \
-                                                                              \
-  develop(ccstr, SharkOnlyCompile, NULL,                                      \
-          "Only compile the specified method")                                \
-                                                                              \
   develop(ccstr, SharkPrintTypeflowOf, NULL,                                  \
           "Print the typeflow of the specified method")                       \
                                                                               \

From gbenson at redhat.com  Wed Oct 28 02:58:32 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 09:58:32 +0000
Subject: Native wrapper compilation and LLVM 2.6
Message-ID: <20091028095832.GA3238@redhat.com>

Hi all,

This past week or so I've been working on making Shark support
compilation of native (JNI) method wrappers.  The way HotSpot
does this has the wrappers being generated outside the compiler
thread, so you have LLVM calls being made from two different
threads.

LLVM < 2.6 doesn't support this, and it's not possible to work
around this with locking; the compiler thread in HotSpot runs
_thread_in_native, which means it cannot hold locks.  (And if
you hack one in there, it deadlocks at the first safepoint ;))

I'm wondering... is anyone using Shark with LLVM < 2.6?  I have
two options here:

 - Write it such that JNI compilation is conditional on
   LLVM >= 2.6.  This requires lots of #ifdefs but is possible.

 - Strip out LLVM < 2.6 support.  This is easier (and neater,
   IMO).  But not really an option if someone depends on it.

What do people think?
   
Cheers,
Gary

-- 
http://gbenson.net/

From aph at redhat.com  Wed Oct 28 03:10:56 2009
From: aph at redhat.com (Andrew Haley)
Date: Wed, 28 Oct 2009 10:10:56 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028095832.GA3238@redhat.com>
References: <20091028095832.GA3238@redhat.com>
Message-ID: <4AE818B0.4010500@redhat.com>

Gary Benson wrote:

> This past week or so I've been working on making Shark support
> compilation of native (JNI) method wrappers.  The way HotSpot
> does this has the wrappers being generated outside the compiler
> thread, so you have LLVM calls being made from two different
> threads.
> 
> LLVM < 2.6 doesn't support this, and it's not possible to work
> around this with locking; the compiler thread in HotSpot runs
> _thread_in_native, which means it cannot hold locks.  (And if
> you hack one in there, it deadlocks at the first safepoint ;))
> 
> I'm wondering... is anyone using Shark with LLVM < 2.6?  I have
> two options here:
> 
>  - Write it such that JNI compilation is conditional on
>    LLVM >= 2.6.  This requires lots of #ifdefs but is possible.
> 
>  - Strip out LLVM < 2.6 support.  This is easier (and neater,
>    IMO).  But not really an option if someone depends on it.
> 
> What do people think?

Shark is advanced technology: I don't think it would hurt to require
LLVM >= 2.6.  The only person who might be badly affected is Ed Nevill,
I suspect.

Andrew.

From gbenson at redhat.com  Wed Oct 28 03:16:27 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 10:16:27 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <4AE818B0.4010500@redhat.com>
References: <20091028095832.GA3238@redhat.com> <4AE818B0.4010500@redhat.com>
Message-ID: <20091028101627.GC3238@redhat.com>

Andrew Haley wrote:
> Gary Benson wrote:
> > This past week or so I've been working on making Shark support
> > compilation of native (JNI) method wrappers.  The way HotSpot
> > does this has the wrappers being generated outside the compiler
> > thread, so you have LLVM calls being made from two different
> > threads.
> >
> > LLVM < 2.6 doesn't support this, and it's not possible to work
> > around this with locking; the compiler thread in HotSpot runs
> > _thread_in_native, which means it cannot hold locks.  (And if
> > you hack one in there, it deadlocks at the first safepoint ;))
> >
> > I'm wondering... is anyone using Shark with LLVM < 2.6?  I have
> > two options here:
> >
> >  - Write it such that JNI compilation is conditional on
> >    LLVM >= 2.6.  This requires lots of #ifdefs but is possible.
> >
> >  - Strip out LLVM < 2.6 support.  This is easier (and neater,
> >    IMO).  But not really an option if someone depends on it.
> >
> > What do people think?
>
> Shark is advanced technology: I don't think it would hurt to
> require LLVM >= 2.6.  The only person who might be badly
> affected is Ed Nevill, I suspect.

He should be ok, I don't think ARM works at all without the
latest and greatest.

Cheers,
Gary

-- 
http://gbenson.net/

From Edward.Nevill at arm.com  Wed Oct 28 03:49:04 2009
From: Edward.Nevill at arm.com (Edward Nevill)
Date: Wed, 28 Oct 2009 10:49:04 -0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028101627.GC3238@redhat.com>
References: <20091028095832.GA3238@redhat.com> <4AE818B0.4010500@redhat.com>
	<20091028101627.GC3238@redhat.com>
Message-ID: <96016C56224DF441A7F553FDC19DA976DAF5CD@ZIPPY.Emea.Arm.com>



>> Shark is advanced technology: I don't think it would hurt to
>> require LLVM >= 2.6.  The only person who might be badly
>> affected is Ed Nevill, I suspect.
>
>He should be ok, I don't think ARM works at all without the
>latest and greatest.

This is fine by me, strip out support for LLVM < 2.6.

Regards,
Ed.

-- 
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

From gbenson at redhat.com  Wed Oct 28 03:58:18 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 10:58:18 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028095832.GA3238@redhat.com>
References: <20091028095832.GA3238@redhat.com>
Message-ID: <20091028105817.GD3238@redhat.com>

Gary Benson wrote:
> This past week or so I've been working on making Shark support
> compilation of native (JNI) method wrappers.  The way HotSpot
> does this has the wrappers being generated outside the compiler
> thread, so you have LLVM calls being made from two different
> threads.
> 
> LLVM < 2.6 doesn't support this, and it's not possible to work
> around this with locking; the compiler thread in HotSpot runs
> _thread_in_native, which means it cannot hold locks.  (And if
> you hack one in there, it deadlocks at the first safepoint ;))
> 
> I'm wondering... is anyone using Shark with LLVM < 2.6?  I have
> two options here:
> 
>  - Write it such that JNI compilation is conditional on
>    LLVM >= 2.6.  This requires lots of #ifdefs but is possible.
> 
>  - Strip out LLVM < 2.6 support.  This is easier (and neater,
>    IMO).  But not really an option if someone depends on it.
> 
> What do people think?

FWIW I wrote a blog explaining this in a bit more detail:
http://gbenson.net/?p=171

Cheers,
Gary

-- 
http://gbenson.net/

From doko at ubuntu.com  Wed Oct 28 04:56:10 2009
From: doko at ubuntu.com (Matthias Klose)
Date: Wed, 28 Oct 2009 12:56:10 +0100
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028095832.GA3238@redhat.com>
References: <20091028095832.GA3238@redhat.com>
Message-ID: <4AE8315A.1090900@ubuntu.com>

On 28.10.2009 10:58, Gary Benson wrote:
> Hi all,
>
> This past week or so I've been working on making Shark support
> compilation of native (JNI) method wrappers.  The way HotSpot
> does this has the wrappers being generated outside the compiler
> thread, so you have LLVM calls being made from two different
> threads.
>
> LLVM<  2.6 doesn't support this, and it's not possible to work
> around this with locking; the compiler thread in HotSpot runs
> _thread_in_native, which means it cannot hold locks.  (And if
> you hack one in there, it deadlocks at the first safepoint ;))
>
> I'm wondering... is anyone using Shark with LLVM<  2.6?  I have
> two options here:
>
>   - Write it such that JNI compilation is conditional on
>     LLVM>= 2.6.  This requires lots of #ifdefs but is possible.
>
>   - Strip out LLVM<  2.6 support.  This is easier (and neater,
>     IMO).  But not really an option if someone depends on it.
>
> What do people think?

I updated llvm to snapshot builds over the last months and updated to the final 
llvm-release for tomorrow's Ubuntu release. Unfortunately this did break openctl 
(not working with 2.6 yet). the 2.6 upstream release doesn't work without 
patches on arm, Xerces already did provide one patch. Not sure about other 
archs, at least shark fails to build eclipse on at least ix86 and powerpc. So 
maybe it's time to include llvm as an optional build item into IcedTea, and 
provide patches/snapshots on IcedTea, as is done for unrelated things like 
visualvm as well.

   Matthias


From gbenson at redhat.com  Wed Oct 28 05:11:01 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 12:11:01 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <4AE8315A.1090900@ubuntu.com>
References: <20091028095832.GA3238@redhat.com> <4AE8315A.1090900@ubuntu.com>
Message-ID: <20091028121101.GG3238@redhat.com>

Matthias Klose wrote:
> On 28.10.2009 10:58, Gary Benson wrote:
> > This past week or so I've been working on making Shark support
> > compilation of native (JNI) method wrappers.  The way HotSpot
> > does this has the wrappers being generated outside the compiler
> > thread, so you have LLVM calls being made from two different
> > threads.
> >
> > LLVM<  2.6 doesn't support this, and it's not possible to work
> > around this with locking; the compiler thread in HotSpot runs
> > _thread_in_native, which means it cannot hold locks.  (And if
> > you hack one in there, it deadlocks at the first safepoint ;))
> >
> > I'm wondering... is anyone using Shark with LLVM<  2.6?  I have
> > two options here:
> >
> >   - Write it such that JNI compilation is conditional on
> >     LLVM>= 2.6.  This requires lots of #ifdefs but is possible.
> >
> >   - Strip out LLVM<  2.6 support.  This is easier (and neater,
> >     IMO).  But not really an option if someone depends on it.
> >
> > What do people think?
>
> I updated llvm to snapshot builds over the last months and updated
> to the final llvm-release for tomorrow's Ubuntu release.

So are you shipping with 2.6 now, or are you still using 2.5 for
some/all releases?

> Unfortunately this did break openctl (not working with 2.6 yet). the
> 2.6 upstream release doesn't work without patches on arm, Xerces
> already did provide one patch.

I thought anything less than 2.6 didn't work on ARM anyway.  Xerxes?

> Not sure about other archs, at least shark fails to build eclipse on
> at least ix86 and powerpc.

Ugh.  Did they work with 2.5?

> So maybe it's time to include llvm as an optional build item into
> IcedTea, and provide patches/snapshots on IcedTea, as is done for
> unrelated things like visualvm as well.

Could do.  Would you be interested in maintaining this?

Cheers,
Gary

-- 
http://gbenson.net/

From gbenson at redhat.com  Wed Oct 28 05:19:42 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 12:19:42 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <fee4d890910280507o59515231p876dc135a701354f@mail.gmail.com>
References: <20091028095832.GA3238@redhat.com>
	<fee4d890910280507o59515231p876dc135a701354f@mail.gmail.com>
Message-ID: <20091028121942.GH3238@redhat.com>

Michael Franz wrote:
> What is the benefit of the native methods being handled differently?
> From your blog, you said the interpreted methods are put on a queue
> to be compiled, the native methods are compiled immediately.
> Couldn't the native methods also be put on the same queue?
> 
> I am not suggesting that LLVM < 2.6 be kept, I am just curious why
> the logic is different.

Looking at the code in HotSpot, it seems that native methods used to
be handled this way, but at some point they were separated out.  In
normal HotSpot I guess there's no reason to queue them as they're
really simple to generate.  I looked at removing the logic that
separates them -- making native methods get queued -- but once you've
created them the code to insert them into the VM differs considerably.
I'm guessing that what happened is once the generation was separated
someone came along and said, "hey, we can really optimize handling of
native methods now", and did a bunch of optimization.  It's not easy
to see how to refactor the compiler interface's insertion code to
handle both cases neatly.

Cheers,
Gary

-- 
http://gbenson.net/

From mvfranz at gmail.com  Wed Oct 28 05:07:36 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Wed, 28 Oct 2009 08:07:36 -0400
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028095832.GA3238@redhat.com>
References: <20091028095832.GA3238@redhat.com>
Message-ID: <fee4d890910280507o59515231p876dc135a701354f@mail.gmail.com>

What is the benefit of the native methods being handled differently?  From
your blog, you said the interpreted methods are put on a queue to be
compiled, the native methods are compiled immediately.  Couldn't the native
methods also be put on the same queue?

I am not suggesting that LLVM < 2.6 be kept, I am just curious why the logic
is different.

On Wed, Oct 28, 2009 at 5:58 AM, Gary Benson <gbenson at redhat.com> wrote:

> Hi all,
>
> This past week or so I've been working on making Shark support
> compilation of native (JNI) method wrappers.  The way HotSpot
> does this has the wrappers being generated outside the compiler
> thread, so you have LLVM calls being made from two different
> threads.
>
> LLVM < 2.6 doesn't support this, and it's not possible to work
> around this with locking; the compiler thread in HotSpot runs
> _thread_in_native, which means it cannot hold locks.  (And if
> you hack one in there, it deadlocks at the first safepoint ;))
>
> I'm wondering... is anyone using Shark with LLVM < 2.6?  I have
> two options here:
>
>  - Write it such that JNI compilation is conditional on
>   LLVM >= 2.6.  This requires lots of #ifdefs but is possible.
>
>  - Strip out LLVM < 2.6 support.  This is easier (and neater,
>   IMO).  But not really an option if someone depends on it.
>
> What do people think?
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/zero-dev/attachments/20091028/1c3ff60a/attachment.html 

From xerxes at zafena.se  Wed Oct 28 07:03:02 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Wed, 28 Oct 2009 15:03:02 +0100
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028121101.GG3238@redhat.com>
References: <20091028095832.GA3238@redhat.com> <4AE8315A.1090900@ubuntu.com>
	<20091028121101.GG3238@redhat.com>
Message-ID: <4AE84F16.2030101@zafena.se>

Gary Benson skrev:
> Matthias Klose wrote:
>   
>> Unfortunately this did break openctl (not working with 2.6 yet). the
>> 2.6 upstream release doesn't work without patches on arm, Xerces
>> already did provide one patch.
>>     
>
> I thought anything less than 2.6 didn't work on ARM anyway.  Xerxes?
>   
LLVM 2.6 are the first LLVM version that can run the JIT stable on
ARM/Linux,
previous versions could only run stable on ARM/Darwin.

"Stable" in this context means passing the LLVM regression testsuite
(llvm$ make test).

>> So maybe it's time to include llvm as an optional build item into
>> IcedTea, and provide patches/snapshots on IcedTea, as is done for
>> unrelated things like visualvm as well.
>>     
>
> Could do.  Would you be interested in maintaining this?
>   
One benefit for Icedtea to maintain a patch queue for a stable LLVM
release are that all distro maintainers can be sure that all shark -XX
debug options actually work!

For example, currently the only way to make the Shark debug build option
-XX:SharkPrintAsmOf=foo work are to apply Aph's patch on llvm that
enables Shark to set and unset llvm debugging flags multiple times. By
having this queue inside icedtea would help new shark to get access to
all shark options more quickly.
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.6/llvm-debugonly-zeroormore.patch

It would also make us more comfortable that we know what configuration
options have been used to build and configure llvm, when we start to
recive bugreports from users.

Yes i would be interested in maintaining a this.
> Cheers,
> Gary
>   

Cheers,
Xerxes

From gbenson at redhat.com  Wed Oct 28 07:16:59 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 14:16:59 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <4AE84F16.2030101@zafena.se>
References: <20091028095832.GA3238@redhat.com> <4AE8315A.1090900@ubuntu.com>
	<20091028121101.GG3238@redhat.com> <4AE84F16.2030101@zafena.se>
Message-ID: <20091028141659.GI3238@redhat.com>

Xerxes R?nby wrote:
> Gary Benson skrev:
> > Matthias Klose wrote:
> > > So maybe it's time to include llvm as an optional build item
> > > into IcedTea, and provide patches/snapshots on IcedTea, as is
> > > done for unrelated things like visualvm as well.
> >
> > Could do.  Would you be interested in maintaining this?
> 
> One benefit for Icedtea to maintain a patch queue for a stable LLVM
> release are that all distro maintainers can be sure that all shark
> -XX debug options actually work!
> 
> For example, currently the only way to make the Shark debug build
> option -XX:SharkPrintAsmOf=foo work are to apply Aph's patch on llvm
> that enables Shark to set and unset llvm debugging flags multiple
> times. By having this queue inside icedtea would help new shark to
> get access to all shark options more quickly.
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.6/llvm-debugonly-zeroormore.patch

Has this patch been submitted upstream to LLVM?

Cheers,
Gary

-- 
http://gbenson.net/

From aph at redhat.com  Wed Oct 28 07:27:41 2009
From: aph at redhat.com (Andrew Haley)
Date: Wed, 28 Oct 2009 14:27:41 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <4AE84F16.2030101@zafena.se>
References: <20091028095832.GA3238@redhat.com>
	<4AE8315A.1090900@ubuntu.com>	<20091028121101.GG3238@redhat.com>
	<4AE84F16.2030101@zafena.se>
Message-ID: <4AE854DD.70304@redhat.com>

Xerxes R?nby wrote:

> 
> For example, currently the only way to make the Shark debug build option
> -XX:SharkPrintAsmOf=foo work are to apply Aph's patch on llvm that
> enables Shark to set and unset llvm debugging flags multiple times. By
> having this queue inside icedtea would help new shark to get access to
> all shark options more quickly.
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.6/llvm-debugonly-zeroormore.patch

Indeed.  I have no idea what it would take to get LLVM to accept this
patch: I've mentioned it twice on the LLVM lists, with no luck.

Andrew.

From gbenson at redhat.com  Wed Oct 28 07:44:21 2009
From: gbenson at redhat.com (Gary Benson)
Date: Wed, 28 Oct 2009 14:44:21 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <4AE854DD.70304@redhat.com>
References: <20091028095832.GA3238@redhat.com> <4AE8315A.1090900@ubuntu.com>
	<20091028121101.GG3238@redhat.com> <4AE84F16.2030101@zafena.se>
	<4AE854DD.70304@redhat.com>
Message-ID: <20091028144421.GJ3238@redhat.com>

Andrew Haley wrote:
> Xerxes R?nby wrote:
> > For example, currently the only way to make the Shark debug build
> > option -XX:SharkPrintAsmOf=foo work are to apply Aph's patch on
> > llvm that enables Shark to set and unset llvm debugging flags
> > multiple times. By having this queue inside icedtea would help new
> > shark to get access to all shark options more quickly.
> > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.6/llvm-debugonly-zeroormore.patch
>
> Indeed.  I have no idea what it would take to get LLVM to accept
> this patch: I've mentioned it twice on the LLVM lists, with no luck.

It's worth asking on #llvm on OFTC.  I'd prefer to get things upstream
rather than maintaining our own mini-fork of LLVM.

Cheers,
Gary

-- 
http://gbenson.net/

From xerxes at zafena.se  Wed Oct 28 07:47:20 2009
From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=)
Date: Wed, 28 Oct 2009 15:47:20 +0100
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <20091028141659.GI3238@redhat.com>
References: <20091028095832.GA3238@redhat.com>
	<4AE8315A.1090900@ubuntu.com>	<20091028121101.GG3238@redhat.com>
	<4AE84F16.2030101@zafena.se> <20091028141659.GI3238@redhat.com>
Message-ID: <4AE85978.4000603@zafena.se>

Gary Benson skrev:
> Xerxes R?nby wrote:
>   
>> Gary Benson skrev:
>>     
>>> Matthias Klose wrote:
>>>       
>>>> So maybe it's time to include llvm as an optional build item
>>>> into IcedTea, and provide patches/snapshots on IcedTea, as is
>>>> done for unrelated things like visualvm as well.
>>>>         
>>> Could do.  Would you be interested in maintaining this?
>>>       
>> One benefit for Icedtea to maintain a patch queue for a stable LLVM
>> release are that all distro maintainers can be sure that all shark
>> -XX debug options actually work!
>>
>> For example, currently the only way to make the Shark debug build
>> option -XX:SharkPrintAsmOf=foo work are to apply Aph's patch on llvm
>> that enables Shark to set and unset llvm debugging flags multiple
>> times. By having this queue inside icedtea would help new shark to
>> get access to all shark options more quickly.
>> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/llvm/llvm2.6/llvm-debugonly-zeroormore.patch
>>     
>
> Has this patch been submitted upstream to LLVM?
>
> Cheers,
> Gary
>
>   
Yes, it have been submitted and poked to the llvm-dev mailinglist frome
time to time:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019661.html  
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-May/022101.html

I could try post the patch on llvm-commit mailing list instead and see
if it can get accepted for inclusion from there.

Cheers
Xerxes

From ed at camswl.com  Wed Oct 28 23:22:32 2009
From: ed at camswl.com (Edward Nevill)
Date: Thu, 29 Oct 2009 06:22:32 +0000
Subject: Native wrapper compilation and LLVM 2.6
In-Reply-To: <96016C56224DF441A7F553FDC19DA976DAF5CD@ZIPPY.Emea.Arm.com>
References: <20091028095832.GA3238@redhat.com> <4AE818B0.4010500@redhat.com>
	<20091028101627.GC3238@redhat.com>
	<96016C56224DF441A7F553FDC19DA976DAF5CD@ZIPPY.Emea.Arm.com>
Message-ID: <1256797352.9725.36.camel@mint>


> -- 
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
>the contents to any other person, use it for any purpose, or store or
>copy the information in any medium.  Thank you.

Yeuch. Sorry about that. Please disregard this utterly pointless and
meaningless drivel.