search for: createregforvalu

...ied to set getTypeToTransformTo(f32) to return f64, even when f64 > is illegal type. But this recursive expansion does not take place with > the current legalizer implementation. Currently, it is assumed that > the > result of getTypeToTransformTo() is a legal type. For example, > CreateRegForValue tries to create a register of such a promoted type > and fails in the above mentioned case. All of the issues can be solved by adding the logic to recursively expand operands. They shouldn't be too complicated. > > > Evan wrote: >> That means, you will have to either 1) m...

...to 2x i32 if needed. I tried to set getTypeToTransformTo(f32) to return f64, even when f64 is illegal type. But this recursive expansion does not take place with the current legalizer implementation. Currently, it is assumed that the result of getTypeToTransformTo() is a legal type. For example, CreateRegForValue tries to create a register of such a promoted type and fails in the above mentioned case. Evan wrote: > That means, you will have to either 1) modify ExpandOp() to > handle cases which need to be recursively expanded or 2) modify it to > return a vector of SDOperand's. Solution...

> >> d) Would it be possible with current implementation of soft-float >> support to map f32/f64 to integer types smaller than i32, e.g. to >> i16? >> I have the impression that it is not necessarily the case, since it >> would require that f64 is split into 4 parts. > > Yes, this should be fine. > >> This question is more about a theoretical

...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 instruction descriptions. And since I still have some insns for load and stores of f64 values (do I still need to have them, if I d...

...return f64, even when > f64 > > is illegal type. But this recursive expansion does not take place > with > > the current legalizer implementation. Currently, it is assumed that > > > the > > result of getTypeToTransformTo() is a legal type. For example, > > CreateRegForValue tries to create a register of such a promoted > type > > and fails in the above mentioned case. > > All of the issues can be solved by adding the logic to recursively > expand operands. They shouldn't be too complicated. > > > > > > > Evan wrote: >...

...ties to tell that f64 is actually represented > as 2xi32. Good, this is the first step. Your goal is to get TLI.getTypeAction(MVT::f64) to return 'expand' and to get TLI.getTypeToTransformTo(f64) to return i32. > 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. Ok. > From what I can see, the problem is that emitNode() still looks at the > machine instruction descriptions. And since I still have some insns for > load and stores of f64 values (do I still need...

...;> f64 >>> is illegal type. But this recursive expansion does not take place >> with >>> the current legalizer implementation. Currently, it is assumed that >> >>> the >>> result of getTypeToTransformTo() is a legal type. For example, >>> CreateRegForValue tries to create a register of such a promoted >> type >>> and fails in the above mentioned case. >> >> All of the issues can be solved by adding the logic to recursively >> expand operands. They shouldn't be too complicated. >> >>> >>> &...

On Tue, 10 Oct 2006, Roman Levenstein wrote: >> I don't understand. If you are writing out the .o file directly, you >> already know how to encode calls... can't you just encode it as the >> right sort of call? > > Yes, sure. I simply overlooked it, because it is too simple and obvious > ;) I was thinking about doing it at a higher level, but this can be >

...rn 'expand' and to get > TLI.getTypeToTransformTo(f64) to return i32. After I sent a mail to the mailing list, I figured out that I need to do this, so I added exactly what you describe and it helped. > > 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. > > Ok. > > > From what I can see, the problem is that emitNode() still looks at > > the machine instruction descriptions. And since I still have some >> insns for >> load and...

> On Tue, 10 Oct 2006, Roman Levenstein wrote: > >>> such a call instruction? > >> > >> Why not just make the asm string be "call __fsub64"? > > > > Well, of course it would be the best solution. But the interesting > part > > is that I need to generate the machine code directly because for > > different reasons use of a system