search for: setcpu

Hi Varun, Have you tried your experiment with icc by any chance? The MCJIT component does not assume that you will be executing the generated code on the host system because it can be used to generate code for external targets. However, you can specify the CPU by calling setCPU() on the EngineBuilder object before creating your execution engine. (You can use sys::getHostCPUName() to figure out what CPU you are running on and that will further detect AVX support, which you don't get with the general "corei7" cpu flag.) I would expect that if you do that it w...

...specific target, corei7 Hi Varun, Have you tried your experiment with icc by any chance? The MCJIT component does not assume that you will be executing the generated code on the host system because it can be used to generate code for external targets. However, you can specify the CPU by calling setCPU() on the EngineBuilder object before creating your execution engine. (You can use sys::getHostCPUName() to figure out what CPU you are running on and that will further detect AVX support, which you don't get with the general "corei7" cpu flag.) I would expect that if you do that it w...

Hi, I am using the LLVM JIT infrastructure (MCJIT). I wanted to see if there are any performance gains as the compiler can detect the target CPU at runtime. But, I didn't see any improvement (I compile with -no-mmx and -no-sse). I then tried an experiment, where I compiled the program with clang-3.3, with and without specifying the target cpu as "corei7". I was shocked to see that

...specific target, corei7 Hi Varun, Have you tried your experiment with icc by any chance? The MCJIT component does not assume that you will be executing the generated code on the host system because it can be used to generate code for external targets. However, you can specify the CPU by calling setCPU() on the EngineBuilder object before creating your execution engine. (You can use sys::getHostCPUName() to figure out what CPU you are running on and that will further detect AVX support, which you don't get with the general "corei7" cpu flag.) I would expect that if you do that it w...

...ang/lib/Basic/Targets.cpp:5596:26: error: 'PK_M' is not a member of 'llvm::ARM' if (ArchProfile == llvm::ARM::PK_M) ^ /export2/src/llvm-trunk/llvm/tools/clang/lib/Basic/Targets.cpp: In member function 'virtual bool {anonymous}::ARMTargetInfo::setCPU(const string&)': /export2/src/llvm-trunk/llvm/tools/clang/lib/Basic/Targets.cpp:5639:48: error: no matching function for call to '{anonymous}::ARMTargetInfo::setArchInfo(llvm::ARM::ArchKind)' setArchInfo(llvm::ARM::parseCPUArch(Name));...

Hi Daniel, > (from the context, you might have meant 'tuple' where you've written > 'triple'. I'm answering based on the assumption you meant 'triple') > > I did mean what I wrote. > The GNU triple is already used as a way of encoding a large amount of the > target data in a string but unfortunately, while this data is passed > throughout

Hi Eric, Thanks for getting back to me on this. > I'm not sure I agree with the basic idea of using the target triple as a way of > encoding all of the pieces of target data as a string. I think in a number of > cases what we need to do is either open up API to the back end to specify things, > or encode the information into the IR when it's different from the generic triple.