search for: gettargetmaxvf

...t; > actually takes up when used as a vector element. > > I prefer to fix the cost model. Do you see any problems with this > approach ? I understand that it is more difficult to select the VF > in the BB vectorizer, but I suspect that even if we add an > additional api (such as getTargetMaxVF) we will run into problems > with non-float data types. There is no problem with fixing the cost model; but doing that will not help the unnecessary compile time increase. Thanks again, Hal > > Thanks, > Nadav > >

...es up when used as a vector element. >> >> I prefer to fix the cost model. Do you see any problems with this >> approach ? I understand that it is more difficult to select the VF >> in the BB vectorizer, but I suspect that even if we add an >> additional api (such as getTargetMaxVF) we will run into problems >> with non-float data types. > > There is no problem with fixing the cost model; but doing that will not help the unnecessary compile time increase. > > Thanks again, > Hal > >> >> Thanks, >> Nadav >> >>

...of bytes that the specified type actually takes up when used as a vector element. I prefer to fix the cost model. Do you see any problems with this approach ? I understand that it is more difficult to select the VF in the BB vectorizer, but I suspect that even if we add an additional api (such as getTargetMaxVF) we will run into problems with non-float data types. Thanks, Nadav

Nadav, et al., On the BG/Q, the vectors hold 4 double-precision values. For vectorizing single-precision code, there are single-precision-rounded instructions, and special load/store instructions, which allow the double-precision numbers to be treated as single-precision numbers. The problem is that the current vectorization code (in the BBVectorizer and, as far as I can tell, also in the