search for: legalizeact

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...

...o 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 uin64_t, see TargetLowering.h. /// > CondCodeActions - For each condition code (ISD::CondCode) keep a /// > LegalizeAction that indicates how instruction selection should /// > deal with the condition code. uint64_t > CondCodeActions[ISD::SETCC_INVALID]; > > What I suggest is the following: > Change the definition of CondCodeAction to: > uint64_t CondCodeActions[ISD::SETCC_INVALID][2]; > &gt...

...deActions 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 uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction that indicates how instruction selection should /// deal with the condition code. uint64_t CondCodeActions[ISD::SETCC_INVALID]; What I suggest is the following: Change the definition of CondCodeAction to: uint64_t CondCodeActions[ISD::SETCC_INVALID][2]; setCondCodeAction then becomes: vo...

...ince we > > are past 32, what LLVM has is broken. > > > > Currently the 4 different Legalize states are stored in successive > > bits and packed into a uin64_t, see TargetLowering.h. /// > > CondCodeActions - For each condition code (ISD::CondCode) keep a /// > > LegalizeAction that indicates how instruction selection should /// > > deal with the condition code. uint64_t > > CondCodeActions[ISD::SETCC_INVALID]; > > > > What I suggest is the following: > > Change the definition of CondCodeAction to: > > uint64_t CondCodeActions[ISD:...

...expanded into a different operation(s) (i.e. SDIVREM => SDIV + SREM or a runtime library call). This can be ambiguous - should a 128-bit SDIVREM be expanded into two 64-bit SDIVREMs or a 128-bit libcall. It would be useful for LLVM to distinguish between these two operations - i.e. instead of LegalizeAction::Expand, we have LegalizeAction::Expand and LegalizeAction::Split. - Expand should always expand the node into a different pattern (such as MULHU expanding to MUL and a copy of the top half). - Split will always split an operation into several smaller, operations (such as 12...

...once I go over this limit llvm starts acting wonky. I found all the items that are hard coded to 32 and a section that isn't, but I cannot figure out how to expand it so that there can be up to 64 data types. The section in question is TargetLowering.h and seems to be these two functions. LegalizeAction getTypeAction(MVT VT) const { if (VT.isExtended()) { if (VT.isVector()) return Expand; if (VT.isInteger()) // First promote to a power-of-two size, then expand if necessary. return VT == VT.getRoundIntegerType() ? Expand : Promote; assert(0...

...to the left and to the right of the '|' operator. Probably not a bug, just some duplicated code. ---- include/llvm/Target/TargetLowering.h:267       switch (getTypeAction(Context, VT)) {       case Legal:         return VT;       case Expand: Note that the values of different enum types (LegalizeAction and LegalizeTypeAction) are compared. This code works well because of the same order for enums, but it would be better to change this into       switch (getTypeAction(Context, VT)) {       case TypeLegal:         return VT;       case TypeExpand: ---- Thanks a lots for any fixes and answers.

...d code. I've CC'd Owen who added this code. > > ---- > > include/llvm/Target/TargetLowering.h:267 > switch (getTypeAction(Context, VT)) { > case Legal: > return VT; > case Expand: > > Note that the values of different enum types (LegalizeAction and > LegalizeTypeAction) are compared. This code works well because of the same order > for enums, but it would be better to change this into > > switch (getTypeAction(Context, VT)) { > case TypeLegal: > return VT; > case TypeExpand: Yup, I...

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

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

...bool IsLegalizingCall; - /// IsLegalizingCallArguments - This member is used only for the purpose - /// of providing assert to check for LegalizeTypes because legalizing an - /// operation might introduce call nodes that might need type legalization. - bool IsLegalizingCallArgs; - enum LegalizeAction { Legal, // The target natively supports this operation. Promote, // This operation should be executed in a larger type. @@ -91,51 +86,12 @@ /// allows us to avoid legalizing the same thing more than once. DenseMap<SDValue, SDValue> LegalizedNodes; - /// Promoted...