search for: computeregisterproperties

...one know if that is true? I looked at a bunch of it but did not want to create a memory leak by calling it again if it was doing a "new" indirectly somewhere. I've created a clearRegisterClasses method so that we can start all over. Then I would add register classes again and call computeRegisterProperties. This is so I can switch processor major modes on a function basis. Tia. Reed

ExpandOp is not called at all. In SelectionDAGLegalize::HandleOp() only the ValueType is considered in the switch statement to decide if it is legal or promote or expand. As I trace back (correct me if I'm wrong) these values are set in TargetLowering::computeRegisterProperties() and it is based on the largest register class (in my case the smallest possible pointer size, 16-bit) So it reduces everything down to 16-bit and pretty much ignores the fact that ADD of i16 is supposed to be expanded. Am I doing the right analysis? Ali. -----Original Message----- From: llvmd...

...t; wrote: > ExpandOp is not called at all. > In SelectionDAGLegalize::HandleOp() only the ValueType is > considered in > the switch statement to decide if it is legal or promote or expand. > As I trace back (correct me if I'm wrong) these values are set in > TargetLowering::computeRegisterProperties() and it is based on the > largest register class (in my case the smallest possible pointer size, > 16-bit) > So it reduces everything down to 16-bit and pretty much ignores the > fact > that ADD of i16 is supposed to be expanded. > > Am I doing the right analysis? Yes. It...

...t; wrote: > ExpandOp is not called at all. > In SelectionDAGLegalize::HandleOp() only the ValueType is > considered in > the switch statement to decide if it is legal or promote or expand. > As I trace back (correct me if I'm wrong) these values are set in > TargetLowering::computeRegisterProperties() and it is based on the > largest register class (in my case the smallest possible pointer size, > 16-bit) > So it reduces everything down to 16-bit and pretty much ignores the > fact > that ADD of i16 is supposed to be expanded. > > Am I doing the right analysis? Yes. It...

...pandOp is not called at all. >> In SelectionDAGLegalize::HandleOp() only the ValueType is >> considered in >> the switch statement to decide if it is legal or promote or expand. >> As I trace back (correct me if I'm wrong) these values are set in >> TargetLowering::computeRegisterProperties() and it is based on the >> largest register class (in my case the smallest possible pointer >> size, >> 16-bit) >> So it reduces everything down to 16-bit and pretty much ignores the >> fact >> that ADD of i16 is supposed to be expanded. >> >> Am I...

...nop for the mips16 compiler, we are able to test that this feature works and that doing things this way allows one to change register sets on a per function basis. The idea here is to add two of the mips32 register sets (including float point which should have a big effect on things) and then computeRegisterProperties() and then revert things to mips16 only registers and call computeRegisterProperties() again. I have several more patches I will need to complete this mips16/nomips16 feature but it's easier to do this in pieces. In the end I will remove this testing code from lib/Target/Mips/Mips16ISelLow...

...pandOp is not called at all. >> In SelectionDAGLegalize::HandleOp() only the ValueType is >> considered in >> the switch statement to decide if it is legal or promote or expand. >> As I trace back (correct me if I'm wrong) these values are set in >> TargetLowering::computeRegisterProperties() and it is based on the >> largest register class (in my case the smallest possible pointer >> size, >> 16-bit) >> So it reduces everything down to 16-bit and pretty much ignores the >> fact >> that ADD of i16 is supposed to be expanded. >> >> Am I...

...i1? I have specified that Hexagon has an i8 predicate register that represents the true predicate as -1 with a sign extend like this: addRegisterClass(MVT::i8, &Hexagon::PredRegsRegClass); setBooleanContents(ZeroOrNegativeOneBooleanContent); and I'm calling this code just before computeRegisterProperties, that builds the TransformToType table specifying the type promotions: i1 -> i8 i8 -> i8 (legal) i16 -> i32 i32 -> i32 (legal) This would be fine if the register for i8 could be used for any integer operation (as in x86 for instance), but on Hexagon, predicate registers can only be...

...at all. >>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>> considered in >>> the switch statement to decide if it is legal or promote or expand. >>> As I trace back (correct me if I'm wrong) these values are set in >>> TargetLowering::computeRegisterProperties() and it is based on the >>> largest register class (in my case the smallest possible pointer >>> size, >>> 16-bit) >>> So it reduces everything down to 16-bit and pretty much ignores the >>> fact >>> that ADD of i16 is supposed to be expanded....

...at all. >>> In SelectionDAGLegalize::HandleOp() only the ValueType is >>> considered in >>> the switch statement to decide if it is legal or promote or expand. >>> As I trace back (correct me if I'm wrong) these values are set in >>> TargetLowering::computeRegisterProperties() and it is based on the >>> largest register class (in my case the smallest possible pointer >>> size, >>> 16-bit) >>> So it reduces everything down to 16-bit and pretty much ignores the >>> fact >>> that ADD of i16 is supposed to be expanded....

Current ISelDagToDag is created once per module. The TargetLowering class is allocated there and register classes are added and the computeRegisterProperties is called. In order to switch back and forth between mips16 and mips32, I need to be able to reset what is done during computerRegisterProperties. Has anyone else looked into this for another port? Ideas? Mips16 is an instruction decoding mode, akin to Thumb 1 and so functions of both mips16...

...poi5", 5>; def POI6: X86Reg<"poi6", 6>; def POI7: X86Reg<"poi7", 7>; def PR128 : RegisterClass<"X86", [i128], 128, (sequence "POI%u", 0, 7)>; However, my debug message in TargetLowering base in its method computeRegisterProperties shows that RegClassForVT[MVT::i128] is still a nullptr. What else should I add for my registers to be a proper destination location of all 128-bit integers? Thanks, Barbora -- ---------------- Barbora Murinová The University of Edinburgh SK: +421905718390 UK: +447477833795 -------------- next pa...

...;> In SelectionDAGLegalize::HandleOp() only the ValueType is >>>> considered in >>>> the switch statement to decide if it is legal or promote or expand. >>>> As I trace back (correct me if I'm wrong) these values are set in >>>> TargetLowering::computeRegisterProperties() and it is based on the >>>> largest register class (in my case the smallest possible pointer >>>> size, >>>> 16-bit) >>>> So it reduces everything down to 16-bit and pretty much ignores the >>>> fact >>>> that ADD of i16 is s...

...exagon has an i8 predicate register that > represents the true predicate as -1 with a sign extend like this: > > addRegisterClass(MVT::i8,&Hexagon::PredRegsRegClass); > setBooleanContents(ZeroOrNegativeOneBooleanContent); > > and I'm calling this code just before computeRegisterProperties, that > builds the TransformToType table specifying the type promotions: > > i1 -> i8 > i8 -> i8 (legal) > i16 -> i32 > i32 -> i32 (legal) > > This would be fine if the register for i8 could be used for any > integer operation (as in x86 for instance), b...

...;> In SelectionDAGLegalize::HandleOp() only the ValueType is >>>> considered in >>>> the switch statement to decide if it is legal or promote or expand. >>>> As I trace back (correct me if I'm wrong) these values are set in >>>> TargetLowering::computeRegisterProperties() and it is based on the >>>> largest register class (in my case the smallest possible pointer >>>> size, >>>> 16-bit) >>>> So it reduces everything down to 16-bit and pretty much ignores the >>>> fact >>>> that ADD of i16 is s...

On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: > Hey folks, > > We are having some difficulty with how we have been representing our > predicate registers, and wanted some advice from the list.  First, we > had been representing our predicate registers as 1 bit (i1).  The truth, > however, is that they are 8 bits.  The reason for this is

On Jul 14, 2014, at 7:23 AM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote: >> Hi all, >> >> What do people think of doing away with the @llvm.convert.to.fp16 and >> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and >> fpext/fptrunc? [1] >> > > I am in favor

...enerate code for the new types 2. LegalizeDAG.cpp - eliminate power-of-2 assumptions in the legalization of extload and truncstore operations. 3. SelectionDAGBuild.cpp - add types to assertsext/assertzext generation in getCopyFromRegs() 4. TargetLowering.cpp - eliminate power-of-2 assumptions in computeRegisterProperties() 5. <Arch>ISelLowering.cpp - specify actions to lower the new types and the operations that use them on all existing architectures (ouch!) Are there more? 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 nee...

Hey folks, We are having some difficulty with how we have been representing our predicate registers, and wanted some advice from the list. First, we had been representing our predicate registers as 1 bit (i1). The truth, however, is that they are 8 bits. The reason for this is that they serve as predicates for conditional execution of instructions, branch condition codes, and also as

...do this. > Specifically it would need to know how to "expand" f64 to 2x i32. I tried to implement it, but I still have some troubles with that. In my understanding, the code in TargetLowering.cpp and also in SelectioNDAGISel.cpp should be altered. I tried for example to modify the computeRegisterProperties to tell that f64 is actually represented as 2xi32. I also added some code into the function FunctionLoweringInfo::CreateRegForValue for allocating this pair of i32 regs for f64 values. But it does not seem to help. >From what I can see, the problem is that emitNode() still looks at the machine...