[LLVMdev] RFC: CondCodeActions refactor (was RE: Why is this assertion here?) (original) (raw)
Hal Finkel hfinkel at anl.gov
Thu Jul 26 14:39:12 PDT 2012
- Previous message: [LLVMdev] RFC: CondCodeActions refactor (was RE: Why is this assertion here?)
- Next message: [LLVMdev] RFC: CondCodeActions refactor (was RE: Why is this assertion here?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Thu, 26 Jul 2012 21:15:35 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote:
Well, I found out the reason why this assert is here, and this is problematic.
CondCodeActions only supports up to 32 different value types. Since we are past 32, what LLVM has is broken. Currently the 4 different Legalize states are stored in successive bits and packed into a uin64t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction that indicates how instruction selection should /// deal with the condition code. uint64t CondCodeActions[ISD::SETCCINVALID]; What I suggest is the following: Change the definition of CondCodeAction to: uint64t CondCodeActions[ISD::SETCCINVALID][2]; setCondCodeAction then becomes: void setCondCodeAction(ISD::CondCode CC, MVT VT, LegalizeAction Action) { assert(VT < MVT::LASTVALUETYPE &&_ _(unsigned)CC < arraylengthof(CondCodeActions) &&_ _"Table isn't big enough!");_ _CondCodeActions[(unsigned)CC][VT.SimplyTy >> 5] &= ~(uint64t(3UL) << (VT.SimpleTy - 32)*2);_ _CondCodeActions[(unsigned)CC][VT.SimpleTy >> 5] |= (uint64t)Action << (VT.SimpleTy - 32)*2; }_ _getCondCodeAction then becomes:_ _LegalizeAction_ _getCondCodeAction(ISD::CondCode CC, EVT VT) const {_ _assert((unsigned)CC < arraylengthof(CondCodeActions) &&_ _(unsigned)VT.getSimpleVT().SimpleTy <_ _MVT::LASTVECTORVALUETYPE && "Table isn't big enough!");_ _LegalizeAction Action = (LegalizeAction)_ _((CondCodeActions[CC][VT.getSimpleVT().SimpleTy >> 5] >> (2*(VT.getSimpleVT().SimpleTy - 32))) & 3); assert(Action != Promote && "Can't promote condition code!"); return Action; }
The other options are to use a BitVector, or to have a different array for each Legalized action. This approach however seems to use the minimum amount of memory/instructions. Ideas?
Your approach seems very similar to how I've fixed this problem locally (I think that the only difference is the order of the arrays). I've attached my version of the fix so that you can compare. I think that, as a practical matter, this is the most economical approach.
-Hal
Micah
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Thursday, July 26, 2012 11:29 AM To: Developers Mailing List Subject: [LLVMdev] Why is this assertion here? I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < arraylengthof(CondCodeActions) &&_ _(unsigned)VT.getSimpleVT().SimpleTy <_ _sizeof(CondCodeActions[0])4 && "Table isn't big enough!");_ LegalizeAction Action = (LegalizeAction) _((CondCodeActions[CC] >> (2VT.getSimpleVT().SimpleTy)) & 3); assert(Action != Promote && "Can't promote condition code!"); return Action; } The first part of the assertion I can understand, but why is there an assertion that there are only 32 types? in TOT LLVM if this code is called with v8f32,v2f64 or v4f64, this assert is triggered. Shouldn't the assert be: (unsigned)VT.getSimpleVT().SimpleTy < MVT::MAXALLOWEDVALUETYPE && or (unsigned)VT.getSimpleVT().SimpleTy < MVT::LASTVECTORVALUETYPE && ? Thanks, Micah
-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- A non-text attachment was scrubbed... Name: ccsize.patch Type: text/x-patch Size: 2275 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120726/59a88290/attachment.bin>
- Previous message: [LLVMdev] RFC: CondCodeActions refactor (was RE: Why is this assertion here?)
- Next message: [LLVMdev] RFC: CondCodeActions refactor (was RE: Why is this assertion here?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]