LLVM projesinde 2025 yılı, özellikle ptradd ve ptrtoaddr talimatlarında önemli ilerlemelere sahne oldu. ptradd geçişi, üç yıldır devam eden bir çabanın parçası olarak, getelementptr (GEP) talimatının tip tabanlı temsilinden uzaklaşarak, bir işaretçiye yalnızca bir tam sayı ofseti ekleyen daha basit bir ptradd talimatına geçişi hedefliyor. Yıl boyunca, tüm GEP talimatları tek bir ofsete sahip olacak şekilde standartlaştırıldı. Örneğin, birden fazla ofset içeren GEP'ler artık iki ayrı talimata bölünüyor. Bu değişiklik, ptradd'in tek ofset argümanı kabul etme hedefine yaklaştırırken, aynı zamanda GEP zincirlerinin Ortak Alt İfade Eleme (CSE) optimizasyonunu da mümkün kılıyor. Bu sürecin en zorlu kısmı, değişikliklerin kendisinden ziyade ortaya çıkan regresyonları gidermek ve birçok dönüşümü zincirlenmiş GEP'ler üzerinde çalışacak şekilde genişletmek oldu. Gelecekte, ptradd'in sabit bir ölçeklendirme faktörünü destekleyip desteklemeyeceği ve yeni formun zorunlu hale getirilmesi gibi önemli adımlar bulunuyor.
LLVM 22 ile tanıtılan yeni ptrtoaddr talimatı ise, ptrtoint ve CHERI mimarileri için işaretçi karşılaştırmalarının semantiği üzerine uzun tartışmaların bir sonucu olarak ortaya çıktı. ptrtoaddr'ın semantiği ptrtoint'e benzer olsa da, iki temel farkı var: İşaretçinin kaynağını (provenance) ifşa etmiyor ve CHERI gibi mimarilerde işaretçilerin taşıdığı ek meta veri bitlerini dışarıda bırakarak sadece adres kısmını döndürüyor. İşaretçiyi bir tam sayıya dönüştürmenin kaynağı ifşa etmeyen bir yolu, LLVM'in provenance hikayesini netleştirmede kritik bir adımdır. Mevcut durumda ptrtoint'in bir yan etkisi olarak provenance'ı ifşa etmesi göz ardı edilirken, ptrtoaddr bu yan etkiden arınmış bir alternatif sunarak bu konunun daha ciddiye alınmasının ön koşullarından birini sağlıyor.
LLVM'deki `ptradd` ve `ptrtoaddr` talimatlarındaki gelişmeler, derleyici altyapısının modern mimarilere uyumunu artırarak performans ve güvenlik optimizasyonları için yeni kapılar açıyor.