Tür Çıkarımı

StableHLO, başlangıçta MHLO lehçesinden önyükleniyordu ve tür çıkarımının MHLO uygulamasını devraldı. Uygulamanın ilerleme durumu status.md içinde izlenir.

Aşağıdaki önerilen yönergeler, StableHLO işlemleri için yüksek kaliteli doğrulayıcılar ve şekil işlevlerinin uygulanmasını sağlamak amacıyla hazırlanmıştır.

Teklif

Bu öneriler, hem mevcut uygulamaların yeniden gözden geçirilmesi hem de kapsamlı bir kapsama ulaşana kadar yeni işlemler elde edilmesi için geçerlidir.

(P1) Doğru bilgi kaynağı olarak StableHLO spesifikasyonunu kullanın

spec, StableHLO işlemlerinin tüm doğrulayıcıları ve şekil işlevleri için bilgi kaynağıdır. Her işlemin mevcut doğrulayıcıları ve şekil işlevlerinin spesifikasyonla tamamen uyumlu olması için tekrar gözden geçirilmesi gerekir. Spesifikasyon belgesinin gelişmeye devam ettiğini unutmayın. Bir işlemin spesifikasyonunun kullanılamadığı durumlarda, bunun yerine bilgi kaynağı olarak XLA uygulaması kullanılmalıdır. Örneğin, xla/service/shape_inference.cc ve xla/service/hlo_verifier.cc. XLA uygulaması sınırsız dinamikliği kapsamaz. Bu nedenle sınırsız dinamizm için RFC dinamizmi hazır olana kadar sağduyulu hareket edeceğiz.

(P2) ODS'den en iyi şekilde yararlanma

ODS dosyaları (StablehloOps.td gibi) her bir işlenen/özellik/sonuç için özellikleri ve türleri olan işlemleri tanımlar ve doğrulamaları yapar. Bu nedenle, zaten ODS tarafından garanti edilen mülklere ilişkin doğrulayıcılarda veya şekil işlevlerinde doğrulama kodu gerekmez. ODS ile kopyalanırsa doğrulama kodu hiçbir zaman tetiklenmeyeceğinden bunları kaldırın.

ODS'deki kısıtlamalar için testler eklememiz gerekir mi? Lütfen Test yönergelerini oluşturma konusuna bakın.

(P3) Doğrulayıcılarda ve şekil işlevlerinde doğrulama kodunu sağlama

Her ikisi:

  • doğrulayıcılar: Op::verify() tarafından uygulanır ve
  • şekil işlevleri: Op::inferReturnTypes() veya Op::inferReturnTypeComponents gibi InferTypeOpInterface tarafından uygulanır

işlem görenleri/özellikleri/sonuçları kontrol etmek için doğrulama kodu olabilir. İlk ayırma şu şekilde olabilir: Doğrulayıcıların işlenenleri/özellikleri kontrol etmesine izin verin, ardından şekil işlevlerinin yalnızca tahmin edilen sonuç türlerini hesaplamasına ve uyumluluğu gerçek sonuç türleriyle karşılaştırarak kontrol etmesine izin verin. Ancak gerçekte bu bölünmenin birkaç sorunu vardır:

  • Şekil işlevi, önce doğrulayıcıyı çağırmadan, otomatik olarak oluşturulan build() işlevleri tarafından çağrılabilir. Dolayısıyla, ilgili girişler şekil işlevinde de doğrulanmalıdır.
  • Yinelenen kod: Örneğin, doğrulayıcılarda işlenenler üzerinde bazı işlemler gerçekleştirir ve ardından bazı ara sonuçları doğrularız. Daha sonra şekil fonksiyonlarında bu ara sonuçlar, nihai sonuçların belirlenmesinde yararlıdır. Bu ara sonuçların iki kez hesaplanması gerekir.
  • Bakım yükü: Bir işlemin doğrulanması iki farklı yöntemle gerçekleştirilir.

Çözüm şu şekildedir:

  1. Bölge içermeyen çoğu işlem için (PadOp gibi): Tüm doğrulama kodunu şekil işlevlerine yerleştirmeye çalışın ve doğrulayıcıları tamamen silin. Dönüş türlerini (ReshapeOp veya BroadcastInDimOp gibi) tahmin edememesi nedeniyle bunun mümkün olmadığı durumlarda gerekli doğrulama mantığını içerecek bir doğrulayıcı oluşturun. AddOp gibi genellikle tahmin edilebilir işlemler, tür/şekil çıkarım yöntemlerinde erişilemeyen sağlanan bir dönüş türünün kısıtlamalarını doğruladıklarından ek doğrulamalar gerçekleştirmek için yine de bir doğrulayıcıya ihtiyaç duyabilir.

  2. Bölge içeren işlemler için (ReduceOp/IfOp gibi; tam listeyi burada bulabilirsiniz): Otomatik olarak oluşturulan oluşturucular, bölgeleri parametre olarak almaz. Bu nedenle, bu oluşturucular tür çıkarımı içeriyorsa şekil işlevi boş bölgelerle çağrılır (bu örneğe bakın).

    1. Tür çıkarımı için bölgeler (ReduceOp gibi) gerekli değilse şekil işlevleri yerine doğrulayıcılara bölgeyle ilgili doğrulama mantığını yerleştirin. Kaçınılmazsa bazı kodları kopyalayın.

    2. Tür çıkarımı (IfOp/CaseOp/MapOp) için bölgeler gerekiyorsa ek olarak şekil işlevi, bölgelerin boş olmadığını açık bir şekilde doğrulamalıdır. Ancak ODS, bu bölgelerin Op tanımında varlığını zaten garanti ediyor olabilir.

(P4) Test yönergelerini oluşturun

ODS kapsamındaki doğrulamalar için test eklememiz/sürdürmemiz gerekir mi?

Biz söz konusu işlemi yapmıyoruz. Testler doğrulayıcılara ve şekil işlevlerine odaklanmalıdır, ODS'de yapılan değişikliklerin tekrar gözden geçirilmesi gerekir.

Ancak eksik parçalara dikkat edin: Örneğin, işlem, öğe türünü değil yalnızca şekilleri kontrol eden SameOperandsAndResultShape özelliğini içeriyorsa işlem görenlerin/sonuçların öğe türlerinin doğrulanması için yine de test gerekir.

Doğrulayıcılar ve tür çıkarımı için testleri nerede yaparız?

ops_stablehlo.mlir, işlem sayısının pozitif olgularını ve her doğrulama hatası için (en az) 1 negatif test içerir. Ayrıca, tahmin edilen dönüş türünün gerçek sonuç türüyle uyumlu olup olmadığını (aynı değil) kontrol edebilir.

infer_stablehlo.mlir hlo_test_infer.get_return_type_components"(%x):... ile satır satır bir işlem işlevinin şekil işlevinin varlığını doğrular ve tahmin edilen türün tam olarak beklendiği gibi eşleşip eşleşmediğini kontrol eder. Genel olarak işlem başına bir pozitif test.

Ne yapmalı?

Bir işlemin doğrulayıcı ve/veya şekil işlevini uygularken ya da tekrar ziyaret ederken:

  1. Tüm pozitif ve negatif olguları ops_stablehlo.mlir dosyasına yerleştirin.

  2. Arayüzü test etmek için infer_stablehlo.mlir dosyasına tek bir pozitif test ekleyin.

  3. (İsteğe bağlı) Bir işlem karmaşıksa ve çok sayıda test içerebilecekse aynı klasöre verify_<op_name>.mlir veya verify_<your_topic>.mlir adlı ayrı bir test dosyası eklemeyi düşünün.