similar to: [LLVMdev] building llvm :: host_os==mingw

On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >> >> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can you step through EngineBuilder::create() and see what's happening there? >> >> -Jim

Hi This llvm-config --libs engine bcreader scalaropts <http://llvm.org/cmds/llvm-config.html> in website http://llvm.org/cmds/llvm-config.html But actually bcreader components is not there anymore. The new name of it is bitreader. I thinks this webpage may need to update and also. If i do "llvm-config --help". It will also show wrong component name in examples g++

Hi all, I'm interested in the LLVM Ocaml bindings so I pulled the current sources from SVN and built them. When I ran the test suite I got the following stats: # of expected passes 2631 # of unexpected failures 7 # of expected failures 11 It looks like some of the failures were due to the Ocaml parts of the tests: FAIL:

On May 14, 2012, at 11:12 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 5/14/2012 10:40 AM, Ashok Nalkund wrote: >>> >>> Hm. OK, that's odd. It should change which constructor gets called in EngineBuilder::create() (which is in lib/ExecutionEngine/ExecutionEngine.cpp). Are you perhaps calling setUseMCJIT(true) after having already called create()? Can

Hi, attached are patches that improve decoding speed a bit. The first patch improves the bit scan macro used for decoding unary values, the second one adds a GCC inline assembly for bswap and the third patch replaces the read_rice_block function. In my testing it turned out to be even faster than the _ia32_bswap function. If the code produced by MSVC is faster as well, I'd suggest to remove

On Mon, Mar 11, 2013 at 08:30:18AM -0400, Ben Allison wrote: > Take, for example, the function FLAC__bitreader_is_consumed_byte_aligned. > It is prototyped in bitreader.h It is used in stream_decoder.c, so it > must be defined and made available to the linker ("external definition"). > However, the only definition in bitreader.c has been declared inline. > > From

Pending positive confirmation in http://llvm.org/PR2886, I'd recommend that r57974 and r57976 be pulled into the 2.4 release branch and configure regenerated there. Begin forwarded message: > From: Gordon Henriksen <gordonhenriksen at mac.com> > Date: October 22, 2008 08:40:40 EDT > To: llvm-commits at cs.uiuc.edu > Subject: [llvm-commits] [llvm] r57974 -

--- src/libFLAC/bitreader.c | 4 ++-- src/libFLAC/bitwriter.c | 4 ++-- src/plugin_xmms/plugin.c | 2 +- src/share/utf8/charset.c | 1 + src/test_libFLAC++/encoders.cpp | 8 ++++---- src/test_libFLAC/decoders.c | 4 ++-- src/test_libFLAC/encoders.c | 8 ++++---- 7 files changed, 16 insertions(+), 15 deletions(-) diff --git a/src/libFLAC/bitreader.c

Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from

Hello. When i run llvm-config --libs jit bitreader bitwriter ipo linker engine i get: -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMX86Info -lLLVMLinker -lLLVMArchive -lLLVMipo -lLLVMBitWriter -lLLVMBitReader -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine

Dagobert Michelsen wrote: > There compilation on Solaris 10 Sparc with Sun Studio 12 gives the following compile errors: > > > CC bitreader.lo > > "bitreader.c", line 494: warning: implicit function declaration: MIN > > CC bitwriter.lo > > "bitwriter.c", line 273: reference to static identifier "bitwriter_grow_" in extern

El 03/05/12 12:19, Miroslav Lichvar escribi?: > Hi Josh, > > nice to see you here again. > > On Wed, Apr 25, 2012 at 04:26:05PM -0700, Josh Coalson wrote: >> (Jumping in again, maybe at the wrong point since this doesn't seem >> to involve encoding, but here goes.) >> >> Miroslav's patches have always been high-quality for sure. But >>

I wrote a patch that enables FLAC__BYTES_PER_WORD==8 in libFLAC/bitreader.c and libFLAC\bitwriter.c. The tests were done on an Intel Nehalem CPU, and flac was compiled with CGG 4.9.x. Average speed increase for FLAC__BYTES_PER_WORD change from 4 to 8: Decoding speed: ia32 architecture 16-bit .flac: -15% 24-bit .flac: -11% x86-64 architecture 16-bit .flac:

Thomas Zander wrote: > If you want to share the patch, I am happy to repeat some testing on > Sandy Bridge and Core2 with clang. The patch changes many files, libFLAC/bitwriter.c and test_libFLAC/bitwriter.c among them. So now I wait for the decision for patches #3 and #4 that I posted yesterday. > The slower decoding speed for 24 bit content on x86_64 seems > surprising, but

Hi all, I have some code that uses the x86 JIT via the C bindings that I'm trying to migrate from targeting LLVM 2.5 to the top of tree, but I'm running into a linking problem I can't figure out. Here's how I'm invoking the JIT in 2.5. LLVMInitializeNativeTarget(); <-- for the updated version LLVMCreateMemoryBufferWithContentsOfFile("code.bc", &buffer,

Op 02-02-16 om 16:54 schreef lvqcl: > BTW, 64-bit flac can benefit from 64-bit words in > bitreader/bitwriter routines. Currently it requires > --enable-64-bit-words switch in ./configure parameters. It > would be interesting to test its effect, especially on ARM. Okay, I might test that as well. I've checked performance with the brand new laptop my employer gave me, which is

Hi all, Second and hopefully final pre-release is here: http://downloads.xiph.org/releases/flac/beta/ I have personally tested this code on: x86-linux x86_64-linux powerpc-linux armhf-linux i386-freebsd9.1 i386-openbsd5.2 I also cross-compiled from Linux to 32 bit Windows and the compile ran to completion (the test suite requires a bunch of hacking before it can

This is about https://llvm.org/bugs/show_bug.cgi?id=27551. Currently there is no easy way to get symbol information out of bitcode files. One has to read the module and mangle the names. This has a few problem * During lto we have to create the Module earlier. * There is no convenient spot to store flags/summary. * Simpler tools like llvm-nm have massive dependencies because Object depends on MC

Keppler, Dave wrote: > Hi all, > > I have some code that uses the x86 JIT via the C bindings that I'm trying to migrate from targeting LLVM 2.5 to the top of tree, but I'm running into a linking problem I can't figure out. > > Here's how I'm invoking the JIT in 2.5. > > LLVMInitializeNativeTarget(); <-- for the updated version >

>> I'm compiling it as follows, which completes with no errors on either >LLVM version. >> >> LLVM_CONFIG=<the llvm-config from the version I want to use> >> gcc `$LLVM_CONFIG --cflags` -o main.o -c main.c >> g++ `$LLVM_CONFIG --cflags` \ >> `$LLVM_CONFIG --ldflags` \ >> main.o `$(LLVM_CONFIG) --libfiles engine BitReader` >>