Bosh sahifa Wiki Loop Fusion

Loop Fusion

Loop Fusion — bir xil yoki mos iteratsiya fazosida ketma-ket bajariladigan ikki yoki undan ortiq siklni bitta siklga birlashtirish optimallashtirishi. Maqsad loop overheadni kamaytirish va ma’lumotning cache’da qayta ishlatilishini yaxshilashdir.

Birlashtirish ta’siri

for i: a[i]=f(i) va undan keyingi for i: b[i]=a[i]+1 birlashtirilsa, har iteratsiyada a yozilib darhol o‘qiladi. Bu a elementining cache’dan chiqib ketish ehtimolini kamaytiradi. Biroq ikki body endi S1(i), S2(i) tartibida aralashadi.

Qonuniylik shartlari

Transformatsiya dependence tartibini saqlashi shart. Agar ikkinchi sikldagi S2(i) birinchi siklning kelajakdagi S1(i+1) natijasiga tayanadigan bo‘lsa, fusion noto‘g‘ri bo‘lishi mumkin. Iteratsiya chegaralari, step, direction va side effectlar ham mos yoki xavfsiz tarzda bo‘linadigan bo‘lishi kerak.

Xarajat modeli

Fusion localityni yaxshilashi mumkin, lekin birlashgan body katta bo‘lsa instruction cache va register pressure oshadi. Ilgari alohida parallel bajariladigan sikllar orasida yangi dependence ko‘rinishi mumkin. Shu sabab cost model faqat loop sonini emas, working set va target arxitekturani baholaydi.

Compiler qarori

Compiler dependence graph, alias analysis va trip count ma’lumotini tekshiradi. Chegaralar qisman mos bo‘lsa prologue, common range va epilogue sikllari yaratilishi mumkin. Runtime alias check static noaniqlikni guard bilan hal qilib, xavfsiz holatda fused variantni tanlaydi.

Sinovlar

Tekshiruv overlapping massivlar, nol iteratsiya, turli lower bound va exceptionli bodylarda original hamda fused natijani solishtiradi. Performance benchmark cold va warm cache holatida alohida o‘tkaziladi. Tezlik oshmasa ham qonuniylik testi muvaffaqiyatli bo‘lishi kerak.

Loop Fusion bo‘yicha tahlil natijasi faqat yakuniy xulosa bilan emas, uni hosil qilgan IR versiyasi, target xususiyatlari va qo‘llangan taxminlar bilan birga saqlanadi. Compiler passlari ketma-ket o‘zgarganda oldingi natija avtomatik ravishda haqiqiy deb olinmaydi: tegishli dependencylar invalidatsiya qilinib, zarur qism qayta hisoblanadi. Debug rejimida asosiy invariant buzilgan nuqta va undan oldingi transformatsiya qayd etiladi; release rejimida esa tekshiruvlarning arzon qismi qoldiriladi. Shu yondashuv nazariy jihatdan qonuniy qoida implementatsiya xatosi yoki noto‘g‘ri cost model sabab zararli qarorga aylangan holatni ajratishga yordam beradi.

Kengaytirilgan jihatlar

Fusion va producer-consumer locality ayniqsa temporary arrayni butunlay yo‘qotishga imkon berishi mumkin. Agar a faqat ikkinchi statementda ishlatilsa, scalar replacement a[i] ni register temporaryga aylantiradi. Bu memory bandwidthni kamaytiradi, ammo a keyin boshqa joyda kerak bo‘lsa massiv store saqlanadi. Parallel looplarda barrier ikki sikl orasida barcha producerlar tugaganini kafolatlagan bo‘lishi mumkin; fusion barrier’ni olib tashlab har i uchun local tartib yaratadi. Bu faqat cross-iteration dependence yo‘qligida xavfsiz. Thread scheduling va false sharing ham cost modelga kiradi.

Fusion qarori oldidan ikkala loopning execution frequency va trip counti tekshiriladi. Biri kamdan-kam shartli bajarilsa, uni majburiy fused loopga qo‘shish ortiqcha ish keltiradi. Code generator fused bodydagi source locationlarni alohida saqlaydi, shunda profiler vaqtni qaysi original statement sarflaganini ko‘rsata oladi.

Compiler remark birlashtirilgan looplar, saqlangan dependence va taxminiy cache foydasini ko‘rsatadi. Transformatsiya rad etilsa, nomos bound yoki xavfli edge aniq qayd etiladi.

Bog‘liq tushunchalar

loop fission, data dependence, cache locality, loop transformation, alias analysis, register pressure