similar to: [LLVMdev] Re: Preferring cast over seteq with 0

Is there a pass that will transform this: %cc = seteq ushort %val, 0 into this: %cc = cast ushort %val to bool Would instcombine be the logical place to do this? Thanks.

On Thu, May 19, 2005 at 03:27:02PM -0500, Eric Zimmerman wrote: > Is there a pass that will transform this: > %cc = seteq ushort %val, 0 > > into this: > %cc = cast ushort %val to bool > > Would instcombine be the logical place to do this? In my situation, this bool value feeds a select instruction. Because casting inverts the condition, the select would have to

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

Okay, let me test with exactly your options and I'll let you know what I get. Reid. On Wed, 7 Jul 2004 19:53:15 +0400 Vladimir Prus <ghost at cs.msu.su> wrote: > Reid Spencer wrote: >> Volodya, >> >> I think you may need to update your CFE and rebuild. I compiled the test >> using my local build and I didn't get the results you see below. I'm

Hello, when I'm compiling test/Programs/SingleSource/UnitTests/2003-05-26-Shorts.c I get LLVM assembler which looks like: int %main(int %argc, sbyte** %argv) { entry: call void %__main( ) %tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16] %tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses= %tmp.5 = cast ulong %tmp.11 to

Okay, I've replicated your results, but I don't think there's an error here, its just not nice output from the disassembler. The first %tmp.ll is of type long. The second one is of type short. I think that's valid for LLVM. That is, the SSA form depends on both the type and name of the virtual register. In any event, llvm-as seems to compile the llvm-dis output just fine. Make

Volodya, I think you may need to update your CFE and rebuild. I compiled the test using my local build and I didn't get the results you see below. I'm also very surprised to see this output. The first %tmp.11 should have been %tmp.1 .. not sure how it got corrupted. In any event, the attachment is obviously generated by code that runs quite differently because the virtual register names

It looks like createCFGSimplificationPass was disabled on 2006/09/04. This causes some problems for architectures that use conditional moves to implement select (alpha and ARM). For example, on 2006/09/03 a "if (a) return 0; else return 1;" compiled to ---------------------------------------- zapnot $17,15,$1 zapnot $16,15,$2 bis $31,$31,$0 cmpeq $2,$1,$1

On 11/2/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > It looks like createCFGSimplificationPass was disabled on 2006/09/04. > This causes some problems for architectures that use conditional moves > to implement select (alpha and ARM). For example, on 2006/09/03 a "if > (a) return 0; else return 1;" compiled to This is not because of how it handles

Hi Reid, On Mon, Jun 20, 2005 at 07:08 -0700, Reid Spencer wrote: > The thing you're missing is that LLVM's primitive types have well known, > fixed sizes that are not target dependent. A ulong is 8 bytes. A uint is > 4 bytes. A ushort is 2 bytes. Etc. and always. Don't aligning rules make it hard to compute the size of a whole struct from the sizes of it's members?

Carl, The thing you're missing is that LLVM's primitive types have well known, fixed sizes that are not target dependent. A ulong is 8 bytes. A uint is 4 bytes. A ushort is 2 bytes. Etc. and always. There are also methods in LLVM to help you deal with the size of a type in bits and bytes. In particular you might want to note the following methods: Type::isSized Type::getPrimitiveSize

Hi, Try as I might, I just cannot get Dir.create_junction to work with FFI in the ffi branch of the win32-dir project. The problem is the REPARSE_JDATA_BUFFER struct. I''m just not sure how to set those members, specifically, the PathBuffer member. The target looks good, it''s UTF-16LE encoded, but I can''t make it work, despite trying several ways of defining the struct,

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.

Dear R-developer (Marsaglia??) The following piece of code from package SuppDist , routine "dist.cc" seems to have a bug ULONG MWC1019(void){ ULONG long t; int i = endQ-1; t = 147669672LL*Q[i] + Q[endQ]; Q[endQ] = (t>>32); if(i>0) return(Q[i--] = t); i = endQ-1; return(Q[0] = t); } in fact , being "i" a local variable that have automatic storage, it is

Hi LLVM-dev! I'm having problems figuring out how to do variable sized structs in LLVM (which are neccessary for PyPy's LLVM backend, on which I'm working). I'm trying to do the equivalent of struct array { long refcount; long length; long items[1]; }; in LLVM, where the items array can be arbitrarily long. I guess that the struct definition should

Hi, Regarding llvm.gcroot, do I have to allocate stack-space for all pointers in a function? Right now I mostly use SSA-variables, and let llvm's register allocation allocate stack-space when needed. Also, what happens when I run the mem2reg pass, does it handle llvm.gcroot's that are moved from stack to registers? I'm thinking along the lines, that should one not use llvm.gcroot on

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19]

Yes, for that you need TargetData: http://illuvium.net/docs/doxygen/classllvm_1_1TargetData.html Reid. On Mon, 2005-06-20 at 17:08 +0200, holger krekel wrote: > Hi Reid, > > On Mon, Jun 20, 2005 at 07:08 -0700, Reid Spencer wrote: > > The thing you're missing is that LLVM's primitive types have well known, > > fixed sizes that are not target dependent. A ulong is

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

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