similar to: [LLVMdev] Additional Optimization I'm Missing?

Displaying 9 results from an estimated 9 matches similar to: "[LLVMdev] Additional Optimization I'm Missing?"

2018 Nov 23
2
is this a bug in an optimization pass?
The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =
2008 Jul 21
6
[LLVMdev] LICM/store-aliasing of global loads
Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to
2018 Jul 20
2
LLVM FunctionType cannot be returned as VectorType?
Dear all, I am using LLVM C++ API to generate some code. In particular, I am dealing with AVX2 SIMD API which uses __m256i. My function input types a set of vectors and return type is also a vector. /////////////////////////////////////////////////////////////////////////////////////////// arguments.push_back(VectorType::get(IntegerType::getIntNTy(TheContext, 64), 4));//int64*4 = __m256i
2018 Jul 23
2
LLVM FunctionType cannot be returned as VectorType?
Hi Stefan, Thank you very much for answering my question! I followed your suggestion but the function still cannot return the correct result. I also set target-feature attributes for my function. I am using LLVM 6.0. It only prints out some random large numbers but the correct answer is supposed to be all 0. Can you please help me figure out what's going on here? Any help will be greatly
2018 Jul 23
2
LLVM FunctionType cannot be returned as VectorType?
Hi Joshua, Thanks for your great comment. I made up a ConstantVector in IR. Then I successfully use AVX intrinsics to retrieve the returned vector data. The remaining thing is that how to pass the vectors to LLVM function using intrinsics. Do you have any suggestions? Please forgive me if the question is too naive. I pasted below two IR I used. The first one works. The second one doesn't.
2010 Feb 17
2
[LLVMdev] Kaleidoscope toy4 failure seg fault on llvm::ExecutionEngine::getTargetData (this=0x0)
I am new to llvm so I might be missing a critical step. My system is Fedora 12 but this also happens in Mac OS X 10.6.2. Here are the steps I used to compile llvm: export TARGETS=x86,x86_64,cpp export INSTALLDIR=/home/rovitotv/llvm ../llvm-2.6/configure --prefix=$INSTALLDIR --enable-bindings=none --enable-targets=$TARGETS --enable-optimized --with-llvmgccdir=$INSTALLDIR
2010 Feb 17
0
[LLVMdev] Kaleidoscope toy4 failure seg fault on llvm::ExecutionEngine::getTargetData (this=0x0)
First, you have to call llvm-g++ to use the llvm-gcc front end, but it doesn't matter here. I'd like to suggest that you use pastebin to put your code and the send us the link, so that we can download it. The problem is that TheExecutionEngine is set to NULL (maybe because of a previous error), but it will be really better if you use pastebin. On Wed, Feb 17, 2010 at 6:01 AM, Todd Rovito
2010 Feb 17
1
[LLVMdev] Kaleidoscope toy4 failure seg fault on llvm::ExecutionEngine::getTargetData (this=0x0)
On Wed, Feb 17, 2010 at 6:29 AM, Conrado Miranda <miranda.conrado at gmail.com> wrote: > First, you have to call llvm-g++ to use the llvm-gcc front end, but it > doesn't matter here. I got the compile command from the Kaleidoscope documentation. > I'd like to suggest that you use pastebin to put your code and the send us > the link, so that we can download it. The
2013 Oct 15
0
[LLVMdev] [llvm-commits] r192750 - Enable MI Sched for x86.
I should mention a couple of useful self-explanatory LLVM flags for triage: -enable-misched=false -verify-misched -Andy On Oct 15, 2013, at 4:43 PM, Eric Christopher <echristo at gmail.com> wrote: > Grats on the work, a long time coming! > > Beware the incoming register allocation bugs ;) > > -eric > > On Tue, Oct 15, 2013 at 4:33 PM, Andrew Trick <atrick at