[llvm-dev] Metadata in LLVM back-end

[David Greene via llvm-dev]

Lorenzo Casalino <lorenzo.casalino93 at gmail.com> writes:

> Am 31/08/20 um 14:10 schrieb David Greene:
>> Lorenzo Casalino via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>
>>> Furthermore, after register allocation there is a non-negligible effort
>>> to properly annotate instructions which share the same output register...
>>>
>>> Concerning the usage of the live ranges to tie annotated instruction and
>>> intrinsic, I have some doubts:
>>>
>>>  1. After register allocation, since metadata intrinsics are skipped
>>> (otherwise,     they would be involved in the register allocation
>>> process, increasing the     register pressure), the instruction stream
>>> would present both virtual and     physical registers, which I am not
>>> sure it is totally ok.

>> They would have to participate in register allocation.

> Should they? I mean: the register allocation "simply" creates a map
> (VirtReg -> PhysReg), and actual register re-writing takes place in a
> subsequent machine pass.

Maybe they could be skipped?  I don't know if there's any precedent for
that.

> So, we could avoid their partecipation in register allocation,
> reducing register pressure and spill/reload work. As a downside, we
> would have intrinsics with virtual registers as outputs, but it is not
> a problem, since they do not perform any real computation.

If we can get that to work, yes I guess having no-op intrinsics with
virtual registers would be ok.  I don't know how the backend post-RA
would cope with that though.  There might be lots of asserts that assume
physical registers.

>> If the intrinsics really shadow "real" instructions then it should be
>> possible to place them such that this is not an issue; for example, you
>> could place them immediately before the "real" instruction.
>
> I do not think this would be possible: before register allocation, code is
> SSA form, thus the annotated instruction *must* preceeds the intrinsic
> annotating it.

Oh yes of course.  Duh.  :)

> An alternative is to place the annotating intrinsic before the
> instruction who ends the specific live-range (not necessarely be an
> immediate predecessor).

I'm not sure exactly what you mean, but it strikes me just now that if
the intrinsic is connected to the target instruction via the target
instruction's output value, then putting the intrinsic right after the
target instruction should not have any live range issues, unless the
target instruction were truly dead, in which case the intrinsic would
keep it alive.  But since the intrinsic would eventually go away, I
assume we could eliminate the target instruction at the same time.

If the target instruction output is used *somewhere* it has a live range
and adding another use just after the def should not affect register
allocation appreciably.  It could of course affect spill choice
heuristics like number of uses of a value but that's probably in the
noise.

It could, however, affect folding (e.g. mem operands) because a single
use of a load would turn into two uses, preventing folding.  It's not
clear to me whether you would *want* folding in your use-case since you
apparently need to do something special with the load anyway.

> Just to point out a problem to cope with: instruction scheduling must be
> aware of this particular positioning of annotation intrinsics.

Probably true.  This is a difficult problem, one I have dealt with.  If
you want to keep two instructions "close" during scheduling it is a real
pain.  ScheduleDAG has a concept for "glue" nodes but it's pretty hacky
and difficult to maintain in the presence of upstream churn.  My initial
attempt to avoid the need for codegen metadata took this approach and it
was quite infeasible.  My second approach to hack in the information in
other ways wasn't much more successful.  :(

I think we've uncovered a number of tricky issues when trying to encode
metadata via intrinsics.  To me, at least, they clearly point to the
need for a first-class solution and I think you agree with that too.
Chris also seemed to at least give tentative support to the idea.

I wonder if we're at the point of drafting an initial RFC for review.

                     -David