[PATCH] D116465: [SPIRV 6/6] Add 2 essential passes and the simplest tests

Aleksandr Bezzubikov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 2 14:38:03 PST 2022


zuban32 added a comment.

In D116465#3292037 <https://reviews.llvm.org/D116465#3292037>, @rengolin wrote:

> I didn't mean the duplicated types/constants would survive into codegen, but I get your meaning, it would have to be commoned up at some point.
>
> So, what about a singleton emitter for types and constants?
>
> Instead of just `get_next_id()` you could have a `get_type(...)` and `get_constant(...)` that returns a cached MIR node if it has created a similar one already, or creates a new one, caches and returns it.
>
> In this way, there's only ever one copy of each and they're only generated once, with no need to deduplicate.
>
> The only issue with this implementation is that types, constants, functions, instructions will all have intertwined IDs, but never refer to larger IDs, by design.
>
> When emitting "int foo()", if `int` hadn't been emitted before, it'd get the next id (say, %23) and then `foo` would get %24 and would refer to %23 as its type.
>
> Eventually, all types used in the program would have been emitted already and be brought up from the cache every time.
>
> This way, there's no need to renumber or common up and the space is still optimal.
>
> What am I missing?

Which stage are you talking about here: InstPrinter, any post-InstructionSelection pass, etc? On gMIR level I don't understand how that'd work if we define VReg %1 in func f1 and then use it in both f1 and f2.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116465/new/

https://reviews.llvm.org/D116465



More information about the llvm-commits mailing list