search for: everywon

Displaying 5 results from an estimated 5 matches for "everywon".

Did you mean: everywone
2010 Nov 26
4
[LLVMdev] LLVMdev Digest, Vol 77, Issue 41
...involved in lifting in new instructions. Then, these passes would be left untouched, for the sake of maintainability. These passes could be copied for fixed point versions. This would mean a just a little slower compiler (dual passes in some cases), for the case of a separation of the code that not everywone is interested in. Then, these passes could be run just by the DSP targets that need them, and the integer developers would not have to worry at all (perhaps by explicitly excluding fixed point instructions here and there, though). Another idea is to introduce a scheme of intrinsics and perhaps h...
2010 Nov 29
2
[LLVMdev] Fw: LLVMdev Digest, Vol 77, Issue 41
...Then, these passes would be > > left untouched, for the sake of maintainability. These passes could > > be copied for fixed point versions. This would mean a just a little > > slower compiler (dual passes in some cases), for the case of a > > separation of the code that not everywone is interested in. Then, > > these passes could be run just by the DSP targets that need them, > > and the integer developers would not have to worry at all (perhaps > > by explicitly excluding fixed point instructions here and there, > > though). > > Ah now it makes...
2010 Nov 26
0
[LLVMdev] LLVMdev Digest, Vol 77, Issue 41
...in new instructions. Then, these passes would be > left untouched, for the sake of maintainability. These passes could > be copied for fixed point versions. This would mean a just a little > slower compiler (dual passes in some cases), for the case of a > separation of the code that not everywone is interested in. Then, > these passes could be run just by the DSP targets that need them, and > the integer developers would not have to worry at all (perhaps by > explicitly excluding fixed point instructions here and there, > though). Ah now it makes sense: you want the existing...
2010 Nov 29
2
[LLVMdev] fixed point types
...passes would be >>> left untouched, for the sake of maintainability. These passes could >>> be copied for fixed point versions. This would mean a just a little >>> slower compiler (dual passes in some cases), for the case of a >>> separation of the code that not everywone is interested in. Then, >>> these passes could be run just by the DSP targets that need them, >>> and the integer developers would not have to worry at all (perhaps >>> by explicitly excluding fixed point instructions here and there, >>> though). >> >...
2010 Nov 30
0
[LLVMdev] fixed point types
...; >>> left untouched, for the sake of maintainability. These passes could > >>> be copied for fixed point versions. This would mean a just a little > >>> slower compiler (dual passes in some cases), for the case of a > >>> separation of the code that not everywone is interested in. Then, > >>> these passes could be run just by the DSP targets that need them, > >>> and the integer developers would not have to worry at all (perhaps > >>> by explicitly excluding fixed point instructions here and there, > >>> thou...