इस दस्तावेज़ में XLA एलियासिंग एपीआई के बारे में बताया गया है. इसकी मदद से, XLA प्रोग्राम बनाते समय इनपुट और आउटपुट बफ़र के बीच का फ़र्क़ तय किया जा सकता है.
कंपाइल के समय उपनाम तय करना
उदाहरण के लिए, एक छोटे से एचएलओ मॉड्यूल पर विचार करें जो बस अपने इनपुट में 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
एपीआई देखें.
रनटाइम के दौरान उपनाम तय करना
पिछले चरण में तय किया गया उपनाम कंपाइलेशन के दौरान बताया जाता है.
प्रोग्राम चलाने के दौरान, LocalClient::RunAsync एपीआई का इस्तेमाल करके यह चुना जा सकता है कि बफ़र को दान करना है या नहीं.
प्रोग्राम के इनपुट बफ़र को ExecutionInputs में रैप किया जाता है, जिसमें MaybeOwningDeviceMemory का ट्री होता है. अगर मेमोरी को ownering के तौर पर बताया गया है (बफ़र का मालिकाना हक XLA रनटाइम को भेजा जाता है), तो असल में बफ़र दान किया जाता है. साथ ही, अपडेट को सही जगह लागू किया जाता है, जैसा कि कंपाइल-टाइम एलियासिंग एपीआई के अनुरोध के मुताबिक किया जाता है.
हालांकि, कंपाइलेशन के समय एलियास किए गए बफ़र को रनटाइम के समय नहीं इस्तेमाल किया जाता है, तो कॉपी-सुरक्षा शुरू होती है: एक और आउटपुट बफ़र O तय किया जाता है और इनपुट बफ़र P के ऐसे कॉन्टेंट को O में कॉपी किया जाता है जो बफ़र O को रनटाइम के दौरान दान किया गया था.