Native method wrapper generation

[Andrew Haley]

Xerxes Rånby wrote:
> Gary Benson wrote:
>> Hi all,
>>
>> This commit adds native wrapper generation to Shark.  It also removes
>> support for LLVM < 2.6, because the new code requires it.  I'll write
>> this up in more detail tomorrow with some benchmarks.
> 
> +void SharkCompiler::generate_native_code(SharkEntry* entry,
> ...
> +#if SHARK_LLVM_VERSION >= 27
> +      if (!fnmatch(SharkPrintAsmOf, name, 0)) {
> +        llvm::SetCurrentDebugType(X86_ONLY("x86-emitter") NOT_X86("jit"));
> +        llvm::DebugFlag = true;
> +      }
> +      else {
> +        llvm::SetCurrentDebugType(""); 
> +        llvm::DebugFlag = false;
> +      }
> +#else
> 
> This part of the code dont work with llvm 2.7svn *release* builds since
> 
> llvm::DebugFlag
> 
> and
> 
> llvm::SetCurrentDebugType
> 
> are only defined in the llvm headers for llvm debug builds.
> 
> This was only a minor issue before the shark rewrite since the code then
> where only included in non product hotspot builds, now it fail on
> product builds as well in combination with a llvm 2.7svn release build.
> One way to fix this would be to introduce a new debug flag based on the
> info from
> llvm-config --build-mode
> that are set to true when llvm-config --build-mode spits out "Debug" ,
> and then conditionalise the code block to be compiled if the new debug
> flag are percent.

But the debug dumps aren't just for people who build their own
OpenJDK, they're useful for debugging the installed OpenJDK and for
people who are just writing apps and want to look at the generated
code.  This is a bad decision on the part of LLVM, but I guess we can
live with it as long as the LLVM packages we use are build with
debugging.

Andrew.