search for: builtin_op_end

...he next available integer arithmetic register: that is i32. Because LLVM automatically legalizes i8 types, it considers all operations to be legal on i8 (i.e., both integer and boolean arithmetic.) So the solution that I was investigating looks like this: for (unsigned int i = 0; i < ISD::BUILTIN_OP_END; ++i) { switch (i) { // By default all operations on i8 have to be promoted to i32. default: setOperationAction(i, MVT::i8, Custom); break; // Only the following operations are legal on i8 predicates. case ISD::AND: case ISD::OR: case ISD::...

...thmetic register: that is > i32. Because LLVM automatically legalizes i8 types, it considers all > operations to be legal on i8 (i.e., both integer and boolean arithmetic.) > > So the solution that I was investigating looks like this: > > for (unsigned int i = 0; i< ISD::BUILTIN_OP_END; ++i) { > switch (i) { > // By default all operations on i8 have to be promoted to i32. > default: > setOperationAction(i, MVT::i8, Custom); > break; > > // Only the following operations are legal on i8 predicates. > case...

...SPISD::BRFCC; > } > return DAG.getNode(Opc, MVT::Other, Chain, Dest, > DAG.getConstant(SPCC, MVT::i32), CompareFlag); Actually, I'm wrong, sorry about that. It looks like the encoding is in the definition of the enum: enum { FIRST_NUMBER = ISD::BUILTIN_OP_END+SP::INSTRUCTION_LIST_END, CMPICC, // Compare two GPR operands, set icc. CMPFCC, // Compare two FP operands, set fcc. BRICC, // Branch to dest on icc condition BRFCC, // Branch to dest on fcc condition ... Are your "targetISD" enums proper...

________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent: Friday, September 19, 2008 10:49 AM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote: I am using lowering instructions and using custom opcodes that

...oad/store work. But it causes llvm to try to use i64 operations for *everything*, which of course fails for all other operations, since there's no such instruction pattern for them. Okay, so I then try setting all the operations to "Expand" via: for (unsigned Op = 0; Op < ISD::BUILTIN_OP_END; ++Op) { setOperationAction(Op, MVT::i64, Expand); } This does not actually work properly. E.g. %res = add nsw i64 %0, 3 gives an error: LLVM ERROR: Cannot select: 0x43b1df0: i64 = add 0x43b1bd0, 0x43b1ce0 [ORD=3] [ID=15] ... Which seems odd -- it appears as if it ignored the Expand...

On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> So the solution that I was investigating looks like this: >> >>      for (unsigned int i = 0; i<  ISD::BUILTIN_OP_END; ++i) { >>        switch (i) { >>        // By default all operations on i8 have to be promoted to i32. >>        default: >>          setOperationAction(i, MVT::i8, Custom); >>          break; >> >>        // Only the following operations are legal on i8 p...

...es llvm to try to use i64 operations for *everything*, which of course fails for all other operations, since there's no such instruction pattern for them. >> >> Okay, so I then try setting all the operations to "Expand" via: >> for (unsigned Op = 0; Op < ISD::BUILTIN_OP_END; ++Op) { >> setOperationAction(Op, MVT::i64, Expand); >> } >> >> This does not actually work properly. E.g. >> %res = add nsw i64 %0, 3 >> gives an error: >> LLVM ERROR: Cannot select: 0x43b1df0: i64 = add 0x43b1bd0, 0x43b1ce0 [ORD=3] [ID=15]...

...>> i32. Because LLVM automatically legalizes i8 types, it considers all >> operations to be legal on i8 (i.e., both integer and boolean arithmetic.) >> >> So the solution that I was investigating looks like this: >> >> for (unsigned int i = 0; i< ISD::BUILTIN_OP_END; ++i) { >> switch (i) { >> // By default all operations on i8 have to be promoted to i32. >> default: >> setOperationAction(i, MVT::i8, Custom); >> break; >> >> // Only the following operations are legal o...

...64 operations for *everything*, which of course fails for all other operations, since there's no such instruction pattern for them. >>>> >>>> Okay, so I then try setting all the operations to "Expand" via: >>>> for (unsigned Op = 0; Op < ISD::BUILTIN_OP_END; ++Op) { >>>> setOperationAction(Op, MVT::i64, Expand); >>>> } >>>> >>>> This does not actually work properly. E.g. >>>> %res = add nsw i64 %0, 3 >>>> gives an error: >>>> LLVM ERROR: Cannot select: 0x43b...

...ctorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: +...

Hi Sebastian, Le 25/05/2012 18:54, Sebastian Pop a écrit : > On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >>> Sebastian, >>> >>> First, it might be useful to look at what is done in the PowerPC >>> backend. PPC also has condition

I 100% get that we might not like the decisions clang-format is making, but how does one overcome this when adding new code? The pre-merge checks enforce clang-formatting before commit and that's a common review comment anyway for those who didn't join the pre-merge checking group. I'm just wondering are we not all following the same guidelines? Concerns of clang-format not being good

On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop <spop at codeaurora.org> wrote: > On Thu, May 24, 2012 at 5:06 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> Sebastian, >> >> First, it might be useful to look at what is done in the PowerPC >> backend. PPC also has condition registers that are larger than the >> 1-bit conditional results, and it defines

...ctorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: +...

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

...ctorValue = false; + for (SDNode::value_iterator J = I->value_begin(); J != I->value_end(); ++J) + HasVectorValue |= J->isVector(); + if (!HasVectorValue) continue; + SDNode* Result = I; + switch (I->getOpcode()) { + default: + assert(I->getOpcode() > ISD::BUILTIN_OP_END && "Unexpected node!"); + break; + case ISD::UNDEF: + case ISD::FORMAL_ARGUMENTS: + case ISD::CALL: + case ISD::MERGE_VALUES: + case ISD::RET: + case ISD::VAARG: + case ISD::Register: + case ISD::INTRINSIC_WO_CHAIN: + case ISD::INTRINSIC_W_CHAIN: +...