این سند XLA Aliasing API را توصیف می‌کند، که به شما امکان می‌دهد هنگام ساخت یک برنامه XLA، نام مستعار بین بافرهای ورودی و خروجی را مشخص کنید.
تعریف نام مستعار در زمان کامپایل
به عنوان مثال، یک ماژول ساده HLO را در نظر بگیرید که به سادگی 1 به ورودی خود اضافه می کند:
HloModule increment
ENTRY entry {
%p = f32[] parameter(0)
%c = f32[] constant(1)
ROOT %out = f32[] add(%p, %c)
}
این ماژول دو بافر 4 بایتی را اختصاص می دهد: یکی برای ورودی %p و دیگری برای خروجی %out .
با این حال، اغلب مطلوب است که به روز رسانی در محل انجام شود (به عنوان مثال، اگر در قسمت جلویی که عبارت را ایجاد می کند، متغیر ورودی پس از محاسبه دیگر زنده نباشد، مانند افزایش p++ ).
برای انجام کارآمد چنین به‌روزرسانی، می‌توانید نام مستعار ورودی را مشخص کنید:
HloModule increment, input_output_alias={ {}: 0 }
ENTRY entry {
%p = f32[] parameter(0)
%c = f32[] constant(1)
ROOT %out = f32[] add(%p, %c)
}
فرمت مشخص می کند که کل خروجی (که با {} مشخص شده است) به پارامتر ورودی 0 نام مستعار باشد.
برای تعیین نام مستعار از نظر برنامه‌ریزی، به XlaBuilder::SetUpAlias API مراجعه کنید.
تعریف نام مستعار در زمان اجرا
نام مستعار تعریف شده در مرحله قبل در هنگام کامپایل مشخص می شود. در طول اجرا، می‌توانید از LocalClient::RunAsync API برای اهدای بافر استفاده کنید.
بافرهای ورودی برنامه در ExecutionInput s پیچیده شده اند که به نوبه خود حاوی درختی از MaybeOwningDeviceMemory هستند. اگر حافظه به عنوان مالک مشخص شود (مالکیت بافر به زمان اجرای XLA منتقل می شود)، بافر در واقع اهدا می شود و به روز رسانی در محل اجرا می شود، همانطور که توسط API مستعار زمان کامپایل درخواست شده است.
با این حال، اگر بافری که در زمان کامپایل نام مستعار داده می شود در زمان اجرا اهدا نشود ، محافظت از کپی آغاز می شود: یک بافر خروجی اضافی O اختصاص داده می شود و محتویات بافر ورودی P که قرار بود نام مستعار داده شود در O کپی می شود. (بطور موثر برنامه می تواند طوری اجرا شود که گویی بافر O در زمان اجرا اهدا شده است).