Отправлено SM 12 октября 2005 г. 12:34 В ответ на: про компилятор(+) отправлено <font color=gray>for(;;)</font> 12 октября 2005 г. 12:13

1) restrict говорит оптимизатору, что он может смело взять данное по указателю, засунуть в регистр, и работать с ним в регистре до упаду. Соответственно, если через какой-то другой указатель это же данное будет изменено, то получится глюк. Два указателя на разные части массива кстати не криминал. В общем юзать аккуратно, зная смысл происходящего :)

2) Еще как может помочь. При конвейеризации цикла часто получается, что цикл может выполняться минимум какое-то кол-во раз. Соответственно компилер, не зная минимального реального числа итераций компилит два цикла - один соптимизированный напрочь, второй - менее соптимизированный, но умеющий от одной итерации исполняться. И ставит условный переход меж них... Это раз. Второе и главное в MUST_ITERATE - это кратность счетчика цикла - если она известна, то компилер может слегка подразвернуть цикл и спараллелить. Тоже полезно.

• про рестрикт - честно говоря не совсем понимаю объяснение — yes   (12.10.2005 13:07 194.133.69.2, 611 байт)
  • Ответ: (+) — SM   (12.10.2005 15:54 195.225.131.183, 1320 байт)
    • вряд ли у BF это другое, но спасибо, вроде понял. только примера (осмысленного), чтобы указатели/массивы в функцию были не рестрикт не представляю — yes   (12.10.2005 16:53 194.133.69.2, 123 байт)
      • А пример такого дела (+) — SM   (12.10.2005 17:05 195.225.131.183, 345 байт)
        • да, понял, что компилер не поймет такую ситуацию без доп. спецификатора — yes   (12.10.2005 17:25 194.133.69.2, 215 байт)
      • Нет, это же не const. Можно и читать и писать, но нельзя указатели на один адрес плодить. Можно const restrict написать, если запись не планируется и алиасинга нет. — SM   (12.10.2005 17:02 195.225.131.183, пустое)
    • Да, SIMD вообще не причем. Да и нет симда у 62хх/67хх — SM   (12.10.2005 15:55 195.225.131.183, пустое)
      • назвать можно и VLIW-ом :) — yes   (12.10.2005 16:59 194.133.69.2, пустое)