similar to: [LLVMdev] [RFC] Replacing EVT:s with MVT:s (when possible)

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

On Dec 3, 2012, at 1:14 PM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this

On Dec 5, 2012, at 4:51 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 3 Dec 2012, at 23:45, Chris Lattner wrote: > >> 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.

On 3 Dec 2012, at 23:45, Chris Lattner wrote: > 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 that takes a legal machine type should take an MVT. A side issue of this is that it is

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)

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 >

Hi all, As Samba users, we often interact with Windows environments. I've developped a PERL script that may be useful to you : it is an .evt (Windows event "log" files) viewer. It is inspired from fccu-evtreader (www.d-fence.be) and displays the contents of an event file. It is available on my website (http://contribs.martymac.com/evtViewer/evtViewer-0.2.tgz) and released under the

I'm new to LLVM dev, but I have been working with a target with a minimum addressable byte of 16-bits. I found that in DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit target which are ultimately invalid. EVT::isRound appears to use a hard-coded 8, rather than pulling the targets BitsPerByte field. Is this a potential bug or is there a better way to address this? Hard

Hi Sam, On 09/07/13 17:01, Sam Cristall wrote: > I'm new to LLVM dev, but I have been working with a target with a > minimum addressable byte of 16-bits. I found that in > DAGCombiner::visitAND, EVT::isRound could create i8 loads on my 16-bit > target which are ultimately invalid. EVT::isRound appears to use a > hard-coded 8, rather than pulling the targets BitsPerByte field.

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 uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction

Hi, I was doing a Kolmogrov test on x, y shown below. They are both 151 long. According to the help file, exact p-value is not available so I set "exact = FALSE", but still got the warning. There are no duplicated values in either X or Y. Thank you for your tips. BTW, is there functions in R about Extreme value theory? ******************************************** > ks.test(x, y,

Yeah just the ordering are the real difference. Also, I use shifts and masks instead of conditionals and modules. My patch is attached. For me either patch is fine, but what LLVM has now is broken. Either patch is fine, just need approval from someone to submit. Micah > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Thursday, July 26, 2012 2:39 PM

On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > On my target store/load of f32 or i32 are equivalents. > Previously I had duplicate instructions def in .td to map f32 and i32 to > the same opcode. > > I deleted all that and I instead tried a new approach (to simplify things) : > > setOperationAction(ISD::STORE, MVT::f32, Promote); >

On Mon, Aug 5, 2013 at 2:25 PM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Aug 05, 2013 at 02:09:58PM -0400, Francois Pichet wrote: > > On my target store/load of f32 or i32 are equivalents. > > Previously I had duplicate instructions def in .td to map f32 and i32 to > > the same opcode. > > > > I deleted all that and I instead tried a new approach

On my target store/load of f32 or i32 are equivalents. Previously I had duplicate instructions def in .td to map f32 and i32 to the same opcode. I deleted all that and I instead tried a new approach (to simplify things) : setOperationAction(ISD::STORE, MVT::f32, Promote); AddPromotedToType(ISD::STORE, MVT::f32, MVT::i32); setOperationAction(ISD::LOAD, MVT::f32, Promote);

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: {

On Sep 2, 2008, at 10:42 AM, David Greene wrote: > Is there an easy way to get the MVT::ValueType of a MachineInstruction > MachineOperand? For example, the register operand of an x86 MOVAPD > should > have an MVT::ValueType of v2f64. A MOVAPS register operand should > have an > MVT::ValueType of v4f32. The short answer is no. A op of a number of different VTs can map to

On Sep 3, 2008, at 1:14 PM, David Greene wrote: > On Tuesday 02 September 2008 16:47, Evan Cheng wrote: >> On Sep 2, 2008, at 10:42 AM, David Greene wrote: >>> Is there an easy way to get the MVT::ValueType of a >>> MachineInstruction >>> MachineOperand? For example, the register operand of an x86 MOVAPD >>> should >>> have an

On Dec 2, 2009, at 12:32 PM, Ken Dyck wrote: > Would there be any interest/opposition to extending the set of simple > integer types in MVT to include the missing multiples of 8 (up to 64 > bits)? That is: i24, i40, i48, i56? > > Adding the types to MVT (and ValueTypes.td) would allow LLVM to be > targeted to architectures that have registers and operations of these > sizes

On Wednesday, December 02, 2009 3:45 PM, Micah Villmow wrote: > > On Wednesday, December 02, 2009 12:33 PM, Ken Dyck wrote: > > > The main drawback of adding the new types is the extra > > burden it would > > put on back ends that don't use them, since they would need to add > > special lowering code for all the types they don't use. On > > the