similar to: [LLVMdev] setCC

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.

Note: Question is written after describing what I have coded. Hello LLVMDevs, I am trying to impliment floating point comparsion for an architecture which supports following type of floating point comparision if FPU is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert unordered comparison to un

It seems like you should be able to statically evaluate these if you assume that NULL is zero and alloca returns an unsigned nonzero pointer value. > 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!

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

On Sun, 9 May 2004, Reid Spencer wrote: > 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

I can't build LLVM CFE after this patchs http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html Build terminated with messages: --8X---------------------------------------------- llvm[2]: Compiling Lexer.cpp for Debug build In file included from

On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > I can't build LLVM CFE after this patchs > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030639.html > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060109/030654.html This is most likely because you have conflict markers in the generated files in the lib/AsmParser directory. Try removing

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

How should we deal with arrays in a structure? should we transform each element of this array to a scalar? Should we consider that the elements of the array are also structure? Thanks! Jianzhong

Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

For VC++, I solved this by having bison/flex put the files into the obj directories. I also have it unconditionally regenerate the files if bison/flex is available, and copy them from src if they are not. Chris Lattner wrote: > On Wed, 11 Jan 2006, Vladimir A. Merzliakov wrote: > >> I can't build LLVM CFE after this patchs >>

hi, The loopinfo pass failed to recognize the Tripcount of a simple program constructed by me, can you help me to figure out why this happened? Thanks. The C program and corresponding .ll files are shown below. I used llvm1.7 to develop my own pass, and want to use the loop information. -Wei Test.c: #include "stdio.h" #define N 40 void func1() { int a[N]; int i,j; for

No solutions come to mind. Conflicts are conflicts and must be resolved manually. This situation should only occur if you change the .l/.y file and then update the .h/.cpp files after someone else has changed the .l/.y file and regenerated the .h and .cpp. That doesn't seem like a high frequency scenario that we need to worry about. Not sure there's much we could do even if it was. Reid.