Çıkarımı Tür

StableHLO, başlangıçta MHLO diyalektinden önyüklendi ve MHLO tür çıkarımı uygulamasını devraldı. Uygulamanın ilerleme durumu status.md üzerinden izlenir.

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

Teklif

Bu teklifler, hem mevcut uygulamaların yeniden gözden geçirilmesi hem de kapsamlı bir kapsama kadar yeni operasyonlar elde edilmesi için geçerlidir.

(P1) Bilgi kaynağı olarak StableHLO spesifikasyonunu kullanın

spec, StableHLO işlemlerinin tüm doğrulayıcıları ve şekil işlevleri için veri kaynağıdır. Her işlemin mevcut doğrulayıcıları ve şekil işlevlerinin spesifikasyonla tam olarak uyumlu hale getirilebilmesi için yeniden gözden geçirilmesi gerekir. Spesifikasyon belgesinin gelişmeye devam ettiğini unutmayın. Bir işlem 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 dinamizm RFC'si kullanılabilir 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 özellik ve türlere sahip işlemleri tanımlar ve doğrulamaları yapar. Bu nedenle, ODS tarafından zaten garanti edilen mülkler için doğrulayıcılarda veya şekil işlevlerinde doğrulama koduna gerek yoktur. ODS ile oluşturulan doğrulama kodunu kaldırın. Bu kod, hiçbir zaman tetiklenmez.

ODS'den gelen kısıtlamalar için test eklememiz gerekir mi? Lütfen Test yönergeleri oluşturma konusuna bakın.

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

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şlenenleri/özellikleri/sonuçları kontrol etmek için doğrulama kodları olabilir. İlk bölme ş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 gerçek sonuç türleriyle uyumluluğu kontrol etmesine izin verin. Ancak, gerçekte bu ayrımın bazı sorunları vardır:

  • Şekil işlevi, önce doğrulayıcıyı çağırmak zorunda kalmadan 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şlenenlerde bazı işlemler gerçekleştirir ve ardından bazı ara sonuçları doğrularız. Şekil fonksiyonlarında bu ara sonuçlar nihai sonuçları çıkarmak için 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ştirin ve doğrulayıcıları tamamen silin.

  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 kabul etmez. 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ı için bölgeler gerekiyorsa (IfOp/CaseOp/MapOp) ayrıca ODS, Operatör tanımında varlığını garanti etse bile şekil işlevinin bölgelerin açık bir şekilde boş olmadığını doğrulaması gerekir.

(P4) Test yönergeleri oluşturma

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

Bu konuda herhangi bir endişemiz yok. Testlerde doğrulayıcılar ve şekil işlevlerine odaklanılmalıdır. ODS'de yapılan değişikliklerin ise bu işlemin tekrar gözden geçirilmesi gerekir.

Ancak eksik parçalar konusunda dikkatli olun: Örneğin, işlem, öğe türünü değil yalnızca şekilleri kontrol eden SameOperandsAndResultShape özelliğini içeriyorsa işlenen öğe/sonuç türleri için doğrulama için yine de test gerekir.

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

ops_stablehlo.mlir, işlem sayısının pozitif olgusunu 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, bir işlemin şekil işlevinin varlığını hlo_test_infer.get_return_type_components"(%x):... ile satır satır 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 fırsatın doğrulayıcı ve/veya şekil işlevini uygularken ya da tekrar gözden geçirirken:

  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.