HLSL offsetting

[Matteo Bruni]

On Fri, Jun 10, 2022 at 1:23 AM Zebediah Figura <zfigura at codeweavers.com> wrote:
>
> On 6/9/22 17:38, Matteo Bruni wrote:
> >> My current vision of SMxIR is that it should be a one-to-one
> >> representation of actual instructions, writable without any lowering
> >> passes (and hence any passes that are done on it should be optimization
> >> only, with the *possible* exception of RA.) In a sense, it's what we
> >> have already with sm4_instruction and such, except that we'd be storing
> >> it and doing passes on it rather than just writing it directly.
> >
> > Right, I agree with the general idea. In practice it might turn out to
> > be useful to relax the 1:1 requirements a bit and introduce some
> > "extra" instructions (that would be quickly lowered to real ones) if
> > that makes the HIR->SMxIR conversion easier.
> >
> > Something related we already discussed: SM1IR and SM4IR are going to
> > be different, obviously, but we want to try and architect them so that
> > the optimization passes machinery and most of the actual passes can be
> > shared between the two.
>
> Hmm, I don't remember that discussion. My take is that if there's only
> two backends it probably makes more sense not to (over-)engineer any
> common framework, but rather just make them look similar enough that we
> can copy-paste things from one to the other. (It's an unpopular opinion,
> perhaps, but I think that code duplication is an important and often the
> best method of code deduplication.)

Actually I think we had this same conversation before and I totally
misremembered your side.

In general, sure, deduplicating stuff a posteriori is the safest
route. Also I think I imagined struct sm1_instruction and struct
sm4_instruction being more similar to each other than they actually
are. So maybe keeping the current separation is a smart idea.
That said, I don't think it's a terrible move to try and keep them
close-ish where it doesn't get in the way. E.g. the sm1 dest register
modifiers are effectively the same thing as the sm4 instruction
modifiers (only 1 dest register in SM1 instruction encoding, arguably
the fact that these modifiers are part of the dest register is more of
an encoding artifact than anything else) so it should be no trouble to
call those "instruction modifiers" in both cases.