similar to: [LLVMdev] LLVM Newbie. Questions about backend.

I am trying to add support for select_cc. In ARM it can be implemented with: mov $dst, $falseVal cmp $a, $b moveq $dst, $trueVal My current strategy is to expand select_cc in two ARM nodes: ARM::SELECT and ARM::CMP. The two nodes would be connected by a flag edge. ARM::CMP would then expand to "cmp $a, $b". This instruction has no results. It only alters the CPSR (current program

A: When the types are created in different contexts. I've been running into a module validation error related to phi nodes produced by the GVN pass, where the types of the incoming values aren't the same instance of IntegerType i1. I'm not certain I've found the root cause of the problem yet, it's probably due to my handling of LLVMContext & Module life cycles, and this

Can someone explain how the condition code is passed from the MBlazeTargetLowering::LowerSELECT_CC to MBlazeTargetLowering::EmitCustomSelect custom inserter? In LowerSELECT_CC the condition code is never accessed (Op.GetOperand(4)) and I don't see how it ends up getting correctly passed to the MBlazeTargetLowering::EmitCustomSelect. > SDValue

Jeremy Lakeman wrote: > A: When the types are created in different contexts. > > I've been running into a module validation error related to phi nodes > produced by the GVN pass, where the types of the incoming values aren't > the same instance of IntegerType i1. > > I'm not certain I've found the root cause of the problem yet, it's > probably due to my

Hi Rafael, > I am trying to add support for select_cc. In ARM it can be implemented > with: > > mov $dst, $falseVal > cmp $a, $b > moveq $dst, $trueVal The more normal ARM code, as produced by assembly writers and compilers that I've seen, is cmp $a, $b moveq $dst, $trueVal movne $dst, $falseVal e.g. at the end of a function returning r0 orr r0, r0, #0x40

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

Hi folks, I'm hitting the below assertion failure when compiling this small piece of C code (repro.c, attached). My command line is: bin/clang --target=aarch64-linux-gnu -c -O2 repro.c clang is built from top of trunk as of this morning. It only happens at -O2, and it doesn't happen with the default target (x86_64). I tried to reproduce using just 'llc -O2' but didn't

Eli, Thanks for the tips. I've been able to get something working using a custom instruction inserter, however, I'm still having the problem of linking together the setcc and the select_cc commands. I want to turn the setcc into a comparison and use the results in the select_cc register. However, the comparison information is in the select_cc instruction and the result of the comparison

On Thu, Sep 11, 2008 at 6:14 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am attempting to lower the selectCC instruction to the instruction set of > the backend I'm working on and I cannot seem to find a way to correctly > implement this instruction. I know how this instruction should get > implemented; I just have yet to find a way to do it. I want the select_cc

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

Thanks for notifying me. Yes, this was a recent change. Taking a look now. On Wed, Jul 20, 2016 at 1:49 PM, Michael Kuperstein <mkuper at google.com> wrote: > +Sanjay, who touched this last. :-) > > On Wed, Jul 20, 2016 at 12:44 PM, Ismail Badawi (ibadawi) via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> I'm hitting the

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

I am attempting to lower the selectCC instruction to the instruction set of the backend I'm working on and I cannot seem to find a way to correctly implement this instruction. I know how this instruction should get implemented; I just have yet to find a way to do it. I want the select_cc instruction to be lowered into a comparison followed by a conditional move. I've attempted to use a

I was able to resolve my previous question about dealing with custom loads/stores, and following Chris' suggestion, the IBM Cell SPU backend can generate code for "int main(void) { return 0; }" without crashing llc. There's a lot of work still to be done... like getting frame offsets correctly computed and hauling in the raft of intrinsics that the Cell SDK defines. Three quick

The only multiplication instruction on my target CPU is multiply-and-accumulate. The result goes into a special register that can destructively read at the end of a sequence of multiply-adds. The following sequence is required to so a simple multiply: acc r0 # clear accumulator, discarding its value (r0 reads as 0, and sinks writes) mac rSRC1, rSRC2 # multiply sources, store

On Apr 18, 2007, at 2:07 PM, Evan Cheng wrote: > > On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > >> I noticed that the TableGen code emitter generator assumes that >> the instruction fields are declared in the instruction format in >> the same order that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match

On Jan 9, 2007, at 10:01 AM, Scott Michel wrote: > I was able to resolve my previous question about dealing with custom > loads/stores, and following Chris' suggestion, the IBM Cell SPU > backend > can generate code for "int main(void) { return 0; }" without crashing > llc. There's a lot of work still to be done... like getting frame > offsets correctly

On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > I noticed that the TableGen code emitter generator assumes that the > instruction fields are declared in the instruction format in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the

I'm working on enhancing TableGen's type checking and it triggered with a problem in CellSPU's specification: XSHWv4i32: (set VECREG:v8i16:$rDest, (sext:v8i16 VECREG:v4i32:$rSrc)) It's complaining that v4i32 is not smaller than v8i16, which is true in the sense of vector bit size, and true in the sense of vector element size. To me, a sign extension from i32 to i16 makes no