• nvcc code 15–18% faster
• nvcc code is bigger and more amenable to stall counts reducing
• all mlir based compilers use vanilla llvm nvptx backend :-(

nvptx uses 58.9% of all ptx instructions

cicc 57.8%

missed in clang:

• _ldsm
• _mma
• discard
• dp2a hi/lo
• madc hi/lo
• p2r
• trap

• llvm doc lies about operand constraint codes
• you can swap operand and this makes parsing/comparison of instructions non-trivial
• nvidia's llvm backend cicc uses ~5-7% of instructions with undocumented attributes and they not available in NVPTX backend from clang

I wrote code to calculate some metrics, like

• count and length of code blocks
• resources usage per block
• resources used in single block

https://redplait.blogspot.com/2026/08/cyclomatic-complexity-of-sass-code.html

The Insights:

• there are lots of Dead / ABI-Forced Register Writes
• Holes in Register Allocation - seems that uniform registers UR0-UR3 almost never used

Can those 2 be expressed in SchedMachineModel?

For example I must track that consequent write after read to the same register must be delayed to ensure that read operation was completed

• The compiler front end does not parse the asm() statement template string and does not know what it means or even whether it is valid PTX input
• order of instruction's attributes (except types of operand) is not important

The combination of these facts leads to stark conclusion - CUDA compiler front-ends totally ignore PTX inline asm and only PTXAS known how to parse them. So I made little and fast parser: https://redplait.blogspot.com/2026/08/parser-of-ptx-instructions.html

Note: this is not full featured replacement of PTX parser. it is designed specifically to extract instruction attributes and determine the correct instruction form based on argument types and counts

and officially open-source

https://github.com/modular/modular/tree/main/KGEN

by relaxing delays for some small set of instructions we can get speed-up 0.2-0.3% for integer-heavy kernels

- ptxas has enough good heuristic

- in average you can reduce ~3% of stall counts

- overall speed up is not equivalent to the number of optimized stall counts

sorry if this is wrong sub-reddit for such questions

Are there some papers/experiments about subj to automatically derive things like indices swizzling/caching in shared memory/pinned memory etc?

https://redplait.blogspot.com/2026/07/identification-of-const-bank0-params.html

I don't have expensive monsters like sm100+ so extracted only params from maxler till hopper

https://redplait.blogspot.com/2026/06/re-of-ptx-grammar-from-ptxas-part-4.html

• names of all pseudo-instructions
• ptx ebnf grammar

You can recover tokens from compiled (f)lex code

Complexity for recovering of single token is O(T * log(T)) where T is size of yy_transition

details: https://redplait.blogspot.com/2026/06/recovering-tokens-from-flex-generated.html

https://redplait.blogspot.com/2026/06/re-of-ptx-grammar-from-ptxas-part-3.html

• revealing bodies of ptx pseudo instructions
• brute-force of (f)lex generated code to identify tokens

https://redplait.blogspot.com/2026/05/re-of-ptx-grammar-from-ptxas-part-2.html

• cicc unable to generate 42% of ptx instructions
• some of them are totally undocumented
• order of attributes is not important

https://redplait.blogspot.com/2026/05/re-of-ptx-grammar-from-ptxas.html

Project in active development, so if you are passionate on PTX, love digging into unstructured data and performing operations on sets, your help is welcomed

https://github.com/NVlabs/cuda-oxide

never used it but seems interesting

official nvidia link https://nvlabs.github.io/cuda-oxide/