[LLVMdev] FP emulation (continued)

[Chris Lattner]

On Fri, 17 Nov 2006, Roman Levenstein wrote:
> I still have some questions about FP emulation for my embedded target.
> To recap a bit:
> My target only has integer registers and no hardware support for FP. FP
> is supported only via emulation. Only f64 is supported. All FP
> operations should be implemented to use i32 registers.

ok

> allocation. But anyway, I have an almost working compiler with integer
> and FP support for my rather specific embedded target! This shows a
> very impressive quality of the LLVM compiler.

Great!

> Another opportunity, as Chris indicated in his previous mails (see
> below), would be to expose the fact that f64 regs really are integer
> registers.

Right.

>> The target independent parts would need to know how to 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.

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 to have them, if I do
> the mapping?), it basically allocates f64 registers without even being
> affected in any form by the modifications described above, because it
> does not use any information prepared there.

If you get here, something is wrong.  The code generator basically works 
like this:

1. Convert LLVM to naive dag
2. Optimize dag
3. Legalize
4. Optimize
5. Select
6. Schedule and emit.

If you properly mark f64 as expand, f64 values should only exist in stages 
1/2/3.  After legalization, they should be gone: only legal types (i32) 
should exist in the dag.

> So, I'm a bit lost now. I don't quite understand what should be done to
> explain the CodeGen how to map virtual f64 regs to the pairs of virtual
> i32 regs? May be I'm doing something wrong? May be I need to explain
> the codegen that f64 is a packed type consisting of 2xi32 or a vector
> of i32???  Chris could you elaborate a bit more about this? What needs
> to be explained to the codegen/legalizer and where?

The first step is to get somethign simple like this working:

void %foo(double* %P) {
   store double 0.0, double* %P
   ret void
}

This will require the legalizer to turn the double 0.0 into two integer 
zeros, and the store into two integer stores.

> Another thing I have in mind is:
> It looks like the easiest way at all would be to have a special pass
> after the assignment of virtual registers, but before a real register
> allocation pass. This pass could define the mapping for each virtual
> f64 register and then rewrite the machine insns to use the
> corresponding i32 regs. The problem with this approach is that I don't
> quite understand how to insert such a pass before physical register
> allocation pass and if it can be done at all. Also, it worries me a bit
> that it would eventually require modifications of PHI-nodes and
> introduction of new ones in those cases, where f64 regs were used in
> the PHI nodes. Now a pair of PHI-nodes would be required for that.
> Since I don't have experience with PHI-nodes handling in LLVM, I'd like
> to avoid this complexity, unless you say it is actually pretty easy to
> do. What do you think of this approach? Does it make sense? Is it
> easier than the previous one, which requires changes in the code
> selector/legalizer?

The best approach is to make the legalizer do this transformation.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/