search for: getcondcodeaction

I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < sizeof(CondCodeActions[0])*4 && "Table isn't big enough!"); LegalizeAction Action = (LegalizeAction)...

..."Table isn't big enough!"); > CondCodeActions[(unsigned)CC][VT.SimplyTy >> 5] &= > ~(uint64_t(3UL) << (VT.SimpleTy - 32)*2); > CondCodeActions[(unsigned)CC][VT.SimpleTy >> 5] |= (uint64_t)Action > << (VT.SimpleTy - 32)*2; } > > getCondCodeAction then becomes: > LegalizeAction > getCondCodeAction(ISD::CondCode CC, EVT VT) const { > assert((unsigned)CC < array_lengthof(CondCodeActions) && > (unsigned)VT.getSimpleVT().SimpleTy < > MVT::LAST_VECTOR_VALUETYPE && "Table isn't big eno...

...ctions) && "Table isn't big enough!"); CondCodeActions[(unsigned)CC][VT.SimplyTy >> 5] &= ~(uint64_t(3UL) << (VT.SimpleTy - 32)*2); CondCodeActions[(unsigned)CC][VT.SimpleTy >> 5] |= (uint64_t)Action << (VT.SimpleTy - 32)*2; } getCondCodeAction then becomes: LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < MVT::LAST_VECTOR_VALUETYPE && "Table isn't big enough!");...

...ig enough!"); > > CondCodeActions[(unsigned)CC][VT.SimplyTy >> 5] &= > > ~(uint64_t(3UL) << (VT.SimpleTy - 32)*2); > > CondCodeActions[(unsigned)CC][VT.SimpleTy >> 5] |= (uint64_t)Action << > > (VT.SimpleTy - 32)*2; } > > > > getCondCodeAction then becomes: > > LegalizeAction > > getCondCodeAction(ISD::CondCode CC, EVT VT) const { > > assert((unsigned)CC < array_lengthof(CondCodeActions) && > > (unsigned)VT.getSimpleVT().SimpleTy < > > MVT::LAST_VECTOR_VALUETYPE && &quo...

...e me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass Regards, Patrik Hägglund -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121203/d72ae610/attachment.html>

...| 3 ++- lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp | 4 ++-- 3 files changed, 9 insertions(+), 9 deletions(-) commit 6e468d9ec25353935c96c78a717e48cb6ace6206 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 16:28:34 2012 +0100 Change TargetLowering::getCondCodeAction to take an MVT, instead of EVT. include/llvm/Target/TargetLowering.h | 12 ++++++------ lib/CodeGen/SelectionDAG/LegalizeDAG.cpp | 4 ++-- lib/CodeGen/SelectionDAG/TargetLowering.cpp | 4 ++-- 3 files changed, 10 insertions(+), 10 deletions(-) commit 0a642d363069fb95a4bdaec598a1d7ba9...

...ist of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: > > getRegClassFor, getRepRegClassFor, getRepRegClassCostFor, setTypeAction, getLoadExtAction, isLoadExtLegal, getTruncStoreAction, isTruncStoreLegal, getIndexedLoadAction, getIndexedStoreAction, getCondCodeAction, getTypeToPromoteTo, addRegisterClass > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything...

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