When the new NVPTX backend was added in commit ae556d3ef72dfe5f40a337b7071f42b7bf5b66a4 the NVPTXAsmPrinter::doInitialization method did not call it's parent AsmPrinter::doInitialization, which would emit module-level inline asm if it existed.
Emitting of module-level inline asm was then added in commit d2bbdf05e0b88524226589d89ffb2bfdc53ef3c8 but this was done without calling AsmPrinter::doInitialization and instead fixed by copying the module-level asm emitting code into NVPTXAsmPrinter::doInitialization after calling NVPTXAsmPrinter::emitHeader
Calling AsmPrinter::doInitialization was then added to NVPTXAsmPrinter::doInitialization in commit 68f2218e1efdb74442987a2040876e2e41f7d90e but NVPTXAsmPrinter::emitHeader was called afterwards, which meant that any module-level inline asm was added before the header which results in invalid ptx.
Also the copied module-level inline asm emitting code was left in, so module-level inline asm was added to the final ptx file twice, once before the header during AsmPrinter::doInitialization in an invalid position and once again after the header during NVPTXAsmPrinter::doInitialization in the correct position.
I have fixed this error by removing the copied module-level inline asm emitting code and adding the NVPTXAsmPrinter::emitHeader call to a new NVPTXAsmPrinter instantiation of the virtual method AsmPrinter::emitStartOfAsmFile which was designed for this use case. I did not add a unit test as one was added in commit d2bbdf05e0b88524226589d89ffb2bfdc53ef3c8 but without calling ptxas -v on every emitted ptx file we can't not verify the correctness, so I'm not sure of the usefulness of the unit test other than to ensure it doesn't cause any internal llvm issues.