search for: expanst

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

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

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

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

...ch and BTW it does not check for getOperationAction or something like that in this case. For example, it tries to expand also all the operations like ADD, SUB, etc into operations on the halves of f64 (probably because it thinks it is an integer ;-) even though for such operations I do not need any expanstion, since they are implemented as library functions. For most of the places assuming the integer type to be expanded, I inserted some code to explicitly check if MVT::f64 is being expanded. This worked for most of the cases, but not for all. In particular I cannot solve the SELECT_CC on f64 expan...

...ot check for getOperationAction or > something like that in this case. For example, it tries to expand also > all the operations like ADD, SUB, etc into operations on the halves of > f64 (probably because it thinks it is an integer ;-) even though for > such operations I do not need any expanstion, since they are > implemented as library functions. Right. These places will have to be updated, and code to handle the new cases needs to be added. > For most of the places assuming the integer type to be expanded, I > inserted some code to explicitly check if MVT::f64 is being exp...

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