search for: eslee3

...[#uses=1] %tmp264not = xor i8 %tmp264, -1 ; <i8> [#uses=2] %a.c45 = or i32 %iftmp.36.0, %tmp261 ; <i32> [#uses=1] trunc i32 %a.c45 to i8 ; <i8>:0 [#uses=1] %tmp268 = or i8 %0, %tmp264not ; <i8> [#uses=1] Ed On Wed, Oct 8, 2008 at 11:59 AM, Edward Lee <eslee3 at uiuc.edu> wrote: > instcombine can handle certain orders of "icmp"s that are "or"ed together: > x != 5 OR x > 10 OR x == 8 becomes.. > x != 5 OR x == 8 becomes.. > x != 5 > > However, a different ordering prevents the simplification: > x == 8 OR x &...

instcombine can handle certain orders of "icmp"s that are "or"ed together: x != 5 OR x > 10 OR x == 8 becomes.. x != 5 OR x == 8 becomes.. x != 5 However, a different ordering prevents the simplification: x == 8 OR x > 10 OR x != 5 becomes.. %or.eq8.gt10 OR x != 5 and that can't be simplified because we now have an "or" OR "icmp". What would I

On Mon, Apr 14, 2008 at 2:50 PM, Edward Lee <eslee3 at uiuc.edu> wrote: > On Mon, Apr 14, 2008 at 5:37 PM, Chris Lattner <sabre at nondot.org> wrote: > > The code generator does CFG simplification to handle cases where blocks > > become dead during lowering. > Oh... is there a way to prevent that from happening? While...

On Mon, Apr 14, 2008 at 5:37 PM, Chris Lattner <sabre at nondot.org> wrote: > The code generator does CFG simplification to handle cases where blocks > become dead during lowering. Oh... is there a way to prevent that from happening? While %x is always 1 and %T is always taken, %F isn't actually dead. There would be a way (with another intrinsic) for control to flow into %F at

I have a simple test .ll file that does something like.. int i = 0; if (argc < 1) i++; else i = foo(i); if (argc < 2) i++; else i = foo(i); if (argc < 3) i++; else i = foo(i); if (argc < 4) i++; else i = foo(i); return i; It gets optimized to just.. return 4; opt -atomic-region-clone -mem2reg -predsimplify -simplifycfg -instcombine .. where -atomic-region-clone is a pass I've

Is there a "standard" way to check for a lock acquire and release for a transformation pass? Assuming the locks aren't inline asm, so llvm-gcc can compile __sync_lock_test_and_set builtin to llvm.atomic.swap, one could potentially look for IntrinsicInst with the appropriate IntrinsicID. But there's many ways to acquire a lock just using the atomic builtins [1] -- not to mention

Is there a way to implement an intrinsic that looks like a conditional branch so that it has 2 edges to 2 basic blocks? Taking a step back, I'm trying to make a special branch where Passes treat it just like a regular conditional branch except that it's condition is opaque to everyone, so it isn't removed by optimizations. Additionally, the special branch would codegen (to x86) to

On Mon, Apr 14, 2008 at 5:11 PM, Chris Lattner <sabre at nondot.org> wrote: > Why not something like: > %x = llvm.myintrinsic() > br i1 %x, label %T, label %F Right. That's exactly what I meant in the last paragraph of the original message. The reason for not wanting this is that %x actually always turns out to be 1 (on architectures that support it), so %T is always

call void @llvm.branchlike(label %thelabel) Is it possible to give a label/BasicBlock* to an intrinsic? Similar to labels for branches. No label type is currently defined in Intrinsics.td, but would it be possible to add it there and ValueTypes.td? But I also want to take the address and put it into a physical register and emit a desired x86 instruction. Assuming I have the label, I should be

I'm trying to put the address of a label in a register by passing in &&label to an inline asm call, but noticed this reduced case also has problems in llvm-g++: int main() { label: return (int)&&label; } The assembly code generated by g++ -S: movl $.L2, %eax ; where L2 is the label just inside main Assembly code from llvm-g++ -S: movl $1, %eax ll code with llvm-g++

On Sat, Apr 19, 2008 at 3:44 PM, Chris Lattner <sabre at nondot.org> wrote: > It sounds like you're doing something STM like, have you contacted > Torvald to see if he has ideas or insight? > http://llvm.org/pubs/2008-02-23-TRANSACT-TangerObjBased.html Yeah, this is TM-like with the begin/end/abort+rollback. Thanks for the pointer, but it seems like Tanger's

On Mon, Apr 14, 2008 at 5:02 PM, Bill Wendling <isanbard at gmail.com> wrote: > Then that flow would be explicit in the CFG, right? Then %F wouldn't > be dead, I'm assuming. Right. That's why I used a conditional branch after the intrinsic, but it sounds like the CFG simplification pass after lowering will optimize it away and no longer have the flow explicit. (To the

On Sat, Apr 19, 2008 at 1:27 PM, Chris Lattner <sabre at nondot.org> wrote: > On Apr 19, 2008, at 1:30 AM, Edward Lee wrote: > > It seems like LLVM happily creates function calls that pass in labels > > but doesn't know how to emit them. > Yep, this isn't supported. We can't quite enforce it as invalid at > this moment, but don't expect it to work.

It seems like LLVM happily creates function calls that pass in labels but doesn't know how to emit them. For the source c code: __asm__ __volatile__ ( ".byte 0x0f, 0x36, 0x00" : : "a" (&&label) : "memory" ); llvm-g++ -emit-llvm generates: tail call void asm sideeffect ".byte 0x0f, 0x36, 0x00",

On Sat, Apr 19, 2008 at 2:16 PM, Chris Lattner <sabre at nondot.org> wrote: > No. The reason we don't allow this is because it violates the CFG. So if I *don't* violate the CFG, would I still need to do something close to "big and nasty"? ; save the address of %otherPath to use later call @llvm.checkpoint(label %otherPath) ; trick the rest of the compiler to

Is there a simple way to require a pass, e.g., Reg2Mem/Mem2Reg, to run before/after my transformation pass? Or do I do something like: struct myOpt { myOpt() { mBefore = createDemoteRegisterToMemoryPass(); mAfter = createPromoteMemoryToRegisterPass(); } getAnalysisUsage(AU) { AU.addRequired(my stuff); mBefore.getAnalysisUsage(AU); mAfter.getAnalysisUsage(AU); }

I have a new instruction that takes 2 labels, and in SelectionDAGISel, I have it doing "CurMBB->addSuccessor()" for both machine blocks. The DAG node it creates also takes both blocks as SDOperands. When I lower to x86, the not-fallthrough block disappears. If I run llc with --fast, the blocks stay around, so it must be an optimization pass of some sort that doesn't realize my