similar to: [LLVMdev] Induction Variables

Hi, I'm working on project which involves writing a backend for a hypothetical architecture. I am currently trying to figure out the best way to translate for loops to use a specialized "loop" instruction the architecture supports. The instruction is similar X86's loop instruction, where a register is automatically decremented and the condition is automatically checked to see if

Hello LLVM, Can you suggest a good way to use the loops and induction variable passes to map loop exiting BasicBlocks to InductionVariables. That is, can we use these tools to identify the loop condition. What i have tried Function Pass: foreach BB if(terminal is loop exit of containing loop) trace back to instruction producing the cond that the branch branches on -

On Wed, 31 Mar 2004, Vladimir Prus wrote: > I've just downloaded the latest release of LLVM, and playing with the > following simple example: > > int main() > { > int r(0); > for (int i = 0; i < 100; ++i) > r += i; > ; > return r; > } When I compiled it, I got the following LLVM code: int %main() { entry: call void %__main( )

Hello, I've just downloaded the latest release of LLVM, and playing with the following simple example: int main() { int r(0); for (int i = 0; i < 100; ++i) r += i; ; return r; } I compile it and then run: analyze -indvars x.bc which prints: Printing analysis 'Induction Variable Analysis' for function 'main': and nothing else. It is a

what's the semantics for setCC if one of the operands is NULL pointer? %ptr=alloc int seteq int*, %pt, NULL what's the result for the second instruction? How about setne, setlt, setgt, setle, and setge? Thanks! Jianzhong

if I write: int z, x; ... z = (x >= k); -- where k is a constant The compiler always wants to translate this into: z = (x > (k-1)); In general this can often lead to better code (and it does for Mips 16 for sure), except at the boundary condition where k==-32768 Then it creates the literal -32769 which cannot be placed in a simple immediate field. That creates a lot of extra code for

Chris Lattner wrote: > > int main() > > { > > int r(0); > > for (int i = 0; i < 100; ++i) > > r += i; > > ; > > return r; > > } > > When I compiled it, I got the following LLVM code: The code I get is somewhat different: int %main() { entry: %tmp.1.i = load bool* %Initialized.0__ ; <bool> [#uses=1] br

> Can you suggest a good way to use the loops and induction variable > passes to map loop exiting BasicBlocks to InductionVariables. That is, > can we use these tools to identify the loop condition. I can try. :) It looks like you're running into problems because we don't perform "Linear Function Test Replacement". This optimization would reduce the amount of code

Before I file a bug, I thought I'd check to make sure something hasn't changed. Stacker used to work in 1.2, now it fails on six tests. All six tests pertain to use of the SetLT, SetGT, SetLE, and SetGE SetCondInst. In my test programs they all fail, regardless of the values. The *only* thing I've done to Stacker is to change the base type involved in the comparison from int to long.

Hello, is there any documentation for LLVM codebase other than produced by doxygen? The reason I'm asking is that doxygen docs are (1) not very complete at the moment, as lot of classes don't even have a description (2) is generally not the best way to get high-level view of a big codebase. As an example, consider this code: %tmp.1 = setgt int %i, 0 br bool %tmp.1, label

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

This is from 'early JIT tests' thread on comp.lang.misc. Given :- int ltst(int x) { int i, j; j=0; for(i=0; i<x; i++)j++; return(j); } This is from the online LLVM compiler. AND It does not seem to optimize it down ! ; ModuleID = '/tmp/webcompile/_24843_0.bc' target datalayout = "e-p:32:32" target endian = little target pointersize = 32 target triple =

Here's some of the generated code from the current community head for bzip2.c from spec 256.bzip2, with these options: clang -m32 -S -O2 bzip2.c .LBB14_4: # %bsW.exit24 subl %eax, %ebx addl $8, %eax movl %ebx, %ecx movl %eax, bsLive shll %cl, %edi movl %ebp, %ecx orl %esi, %edi

I am having trouble understanding the relationship between LLVM identifiers, stack (alloca) and variables. In particular, when I need to create a variable, what should I use? For instance, consider the following C-like language snippet: int f() { int i = rand(); if(i > 5) i = 1; return i; } Ignoring optimizations, what should I use to represent 'i'? Online demo gives the following

FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll: %Y = cast sbyte %SB to uint ; <uint> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast ubyte %SB to uint ; <uint> [#uses=1] %Y = cast ubyte %SB to

Thanks Kevin. This isn't exactly what I'm looking for, though. The ECX is explicitly defined here and CL/CH are only used. I was interested in the opposite situation---where the sub-registers are defined separately and then the super-register is used as a whole. Hopefully the sub-register liveness tracking is what I need, so the questions about x86 may become moot. -Krzysztof

On Thu, 22 Apr 2004, Vladimir Prus wrote: > > I'm wondering what was the original motivaton for the 'select' > instruction. Was it for convenience, or for some deep reason. I'm > asking because it's causing me some problems (see below) and I'd like to > know I understand the situation before working those problems around. The select instruction is

Chris Lattner wrote: > The select instruction is basically an SSA-form "conditional move", or a > very simple form of predication. Integer codes often have very complex > CFG's which are usually doing simple things. For example, it's not > uncommon to see something like this: > > if (blah) > X = 14; > > If the body of the if statement is simple

I linked the wrong patch review. Here's the patch that was actually committed: https://reviews.llvm.org/D48508 https://reviews.llvm.org/rL335433 On Tue, Jul 3, 2018 at 4:39 PM, Sanjay Patel <spatel at rotateright.com> wrote: > [adding back llvm-dev and cc'ing Craig] > > I think you are asking if we are missing a fold (or your target is missing > enabling another hook)

Hello! I'm compiling code which uses pointers as iterators. For some reason--probably a silly misunderstanding of the docs--I can't eliminate duplicate pointer loads. I'll probably figure this out eventually, but if somebody else sees the answer instantly, I certainly won't complain. :-) Here are the optimizers I'm running: opt -f -simplifycfg -dce -instcombine