[Comgr][HotSwap] Refactor hotswap related files into their own directory

[chinmaydd]

No description provided.

[harsh-amd]

Just thinking out aloud here: is raiser vs rewriter the right long term abstraction here? Should we instead split it up into phases, like parse code object, discover kernels, classify source/target ISA, choose transform strategy, run transforms, update metadata/debug info, emit code object. “Rewriter” and “raiser” are execution strategies inside that pipeline, not the pipeline itself. How about something instead like:

 hotswap/
    core/              
    transforms/
      binary/
      ir/
        raise/

where
core owns the shared hotswap pieces like targets, options, code-object/kernels, diagnostics.
transforms/binary owns direct machine-code / ELF patching
transforms/ir owns raise-to-IR, LLVM lowering, and code-object re-emission

and eventually we can get a planning directory which decides what strategy to use for different kernels.

[chinmaydd]

Thanks for engaging.

There's a couple of ways one can think about this.

The "transforms" framing makes sense if we envision that the raiser can be applied after the rewriter has made a pass-through. This may be relevant for patches or transformations that require a full-program view.

However, this is very tricky because as soon as the rewriter has run, one is assuming fixed-placement (relative or otherwise) for certain instructions. When you raise to IR, you are effectively forgoing that. The compiler may choose a different lowering or move things around. Maybe we can have a strict mode that inserts compiler barriers before and after every instruction to prevent that.

On the other hand, it may make sense to run the rewriter to run after raiser to take care of some corner cases that may not be fixable though LLVM IR. For this use case, thee raiser needs to support raising and recompiling a specific set of functions. This can be hard for indirect calls, but you can add trampolines to original function addresses to achieve that.

We need to clear up the long term vision here. My thought process aligns more towards:

hotswap/
   utils/
     <code object parsing, inst assembly, etc.>
   lib/
     rewriter/    <-- uses common utils
       patches/
     raiser/      <-- uses common utils
       passes/
   tools/
     rewriter.cpp
     raiser.cpp

Fundamentally, even though the modifications performed by the raiser and the rewriter are "transforms" I think keeping them separate and closely tied to their respective tools makes more sense to me.

The raiser is going to operate at an entirely different abstraction i.e LLVM IR whereas the rewriter only looks at machine code (ideally, I would have liked for us to atleast do this at the MCInst layer like BOLT does).