search for: expanstions

...> This will probably require a slightly more extensive patch to >> legalizer. The current mechanism assumes either 1->1 or 1->2 >> expansion. > > Exactly. This is what I meant with "more chellenging";) It is assumed > at several places that 1->1 or 2->2 expanstions are taking place. A > generic case is not handled yet. > >> It also assumes the result of expansion are of legal >> types. > > Yes. And this is also a reason why it is not too obvious how to handle > f32->f64 promotion and later f64->i64 expansion on targets that...

...> > > > This will probably require a slightly more extensive patch to > legalizer. The current mechanism assumes either 1->1 or 1->2 > expansion. Exactly. This is what I meant with "more chellenging";) It is assumed at several places that 1->1 or 2->2 expanstions are taking place. A generic case is not handled yet. > It also assumes the result of expansion are of legal > types. Yes. And this is also a reason why it is not too obvious how to handle f32->f64 promotion and later f64->i64 expansion on targets that support only f64 soft-floats....

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

...e a slightly more extensive patch to > >> legalizer. The current mechanism assumes either 1->1 or 1->2 > >> expansion. > > > > Exactly. This is what I meant with "more chellenging";) It is > assumed > > at several places that 1->1 or 2->2 expanstions are taking place. A > > generic case is not handled yet. > > > >> It also assumes the result of expansion are of legal > >> types. > > > > Yes. And this is also a reason why it is not too obvious how to > handle > > f32->f64 promotion and later...

...xtensive patch to >>>> legalizer. The current mechanism assumes either 1->1 or 1->2 >>>> expansion. >>> >>> Exactly. This is what I meant with "more chellenging";) It is >> assumed >>> at several places that 1->1 or 2->2 expanstions are taking place. A >>> generic case is not handled yet. >>> >>>> It also assumes the result of expansion are of legal >>>> types. >>> >>> Yes. And this is also a reason why it is not too obvious how to >> handle >>> f32-&gt...

Hi Chris, Thank you very much for your answer! It helps me to move in the right direction. When you explain it, it sounds rather easy. But I still have some tricky issues. This is either because I'm not so familiar with LLVM or because it is a bit underestimated how much LLVM legalizer/expander relay on expandable types to be integers (see my explanations below). --- Chris Lattner <sabre

On Mon, 20 Nov 2006, Roman Levenstein wrote: >> 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. > > Sample code

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

Hi, 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. Based on the fruitful discussions on this list I was already able to implement mapping of the FP operations to