similar to: [LLVMdev] 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? >> >> In my situation, this bool value feeds a select instruction. Because >> casting inverts the condition, the select would have to switch the

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

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

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

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

I tried to optimize the following code using opt -load-vn -sccp -dcse, but no effect. The loading and storing of unique should be removed, and branch should be statically evaluated. Any suggestions? The code: %tmp.0 = call int %acquireLock( ) ; <int> [#uses=0] store int 1, int* %unique %load = load int* %unique ; <int> [#uses=1] %Set = seteq int 1, %load ; <bool> [#uses=1]

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]

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

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

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

On Fri, 12 May 2006, Silken Tiger wrote: > To find the first instructions which are not depending on others results. So > far it seems to be working but i am missing instructions like: > %tmp.1 = seteq int %argc, 2 ; <bool> [#uses=1] > There seems only an function like llvm::Instruction::mayWriteToMemory > but nothing like llvm::Instruction::mayReadFromMemory or

On Sun, 22 Apr 2007, Christopher Lamb wrote: > 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

Hi I am currently trying to schedule instructions with my own algorithm. For that i need to get the data dependency between the instructions. So currently i am dooing s.t. like: for(BasicBlock::iterator j=B.begin(),bbe=B.end();j!=bbe;++j) { InstructionList.push_back(j); if (const AllocaInst *AI = dyn_cast<AllocaInst>(j)) {

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

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, 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,

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much slower > than GCC, so I decided to take a look and see why that is so. The program > has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { > int i,j; > > for