windows deep internals

In my previous post I discovered that SASS register allocation can have holes - non-contiguous register indices allocated to a function where intermediate registers like R57 remain unused despite R56 and R58 being live/allocated To estimate size of problem

Many algorithms of my SASS optimizer work with code blocks.

A couple of facts to start things off From official "Inline PTX Assembly in CUDA": 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 And second, less well-known…

In part 1 I suggested that "native" latency tables are too conservative and can be relaxed for some instructions.

Optimal instructions scheduling is NP-hard task.

Official documentation doesn't disclose ConstBank0 (c[0x0]) memory layout used at the SASS level for kernel arguments and special registers (like %gridid, %nctaid) So I've spent last week trying to solve this deceptively simple problem.

Parts 1, 2 & 3 First of all, it should be noted that the mask of instruction attributes has size 20 bytes, so I updated dump for them. structure for this attributes descriptor has size 0xd8 bytes and some fields: mask at offset 0 name of instruction at 0x…

While doing some reverse engineering of ptxas I discovered that their lexer was generated by lex in fast mode (lex -f).

Parts 1 & 2 Pseudo instructions Surprise-surprise - some PTX instructions not mapped directly to underlying SASS 1:1.

Part 1 PTX instructions that cicc cannot generate While reverse-engineering Nvidia's compilation pipeline, I extracted the set of PTX instructions that cicc (the CUDA C++ frontend) is capable of emitting.

Disclaimer Highly likely that author is an illiterate, inattentive, and incompetent lazy person with a poor imagination - therefore his hypotheses may be questionable, ideas delusional and his analysis simply incorrect.

After extracting latency table I became curious how good the code produced by ptxas.

method 1 requires building of hijacked .so with appropriate LLVM version.

I've add some support of DWARF debug info from nvidia nvcc to my dwarfdump.

LLVM Compiler for RISC-V Architecture Describes details of risc-v vectorization support in llvm.

In my first attempt I used latency tables extracted from MD file (located inside nvdisasm) and nothing good came out of it Obvious reason is that real latency table should be located not in disassembler - it must be inside ptxas.

I've done some research of libcudadebugger.so internals - seems that it has exactly the same patterns: functions table returned by GetCUDADebuggerAPI located in .data section so you can patch any callback address and each API function has logger This last…

For some reason cuda-gdb from cuda sdk gives on my machine list of errors like Traceback (most recent call last): File "/usr/share/gdb/python/gdb/__init__.py", line 169, in _auto_load_packages __import__(modname) File "/usr/share/gdb/python/gdb/command/ex…

inconvenient cuda-gdb can't automatically processing them - you need explicitly say something like target cudacore /full/path/to/coredump and then type lots of info cuda XXX So last weekend I wrote tool to parse/dump CUDA coredumps and it even works on ma…

As illustration of ideas from my previous blogpost I made PoC for logging all libcuda.so calls - as the cuda-gdb debugger sees them It just installs own debug handler and receives all messages.

Previous part I've noticed that almost all real API functions has the same prologues like: mov eax, cs:dword_5E14C00 ; unique for each API function mov [rbp+var_D0], 3E7h mov [rbp+var_C0], 0 mov [rbp+var_C8], 0 test eax, eax jz short loc_39603B lea rdi, […

The first question that comes to mind when looking at them is "why they are so huge?".

Spent couple of days in debugging rare bug in my sass disasm.

In these difficult times, no one wants to report bad or simply weak results (and this will destroy this hypocritical civilization).

Lets continue to compose some useful things based on perl driven Ced.