[llvm-dev] Metadata in LLVM back-end

[David Greene via llvm-dev]

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

>>> 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
>
> I mean, to avoid artificial extension of the live-range, place the
> annotating intrinsic (I) before the instruction (K) that kills the
> live-range (but the intrinsic (I) does not have to be an *immediate*
> predecessor of (K) in the instruction stream).

Ok, got it.  Thanks!

>> 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.
>
> Uhm...yes, folding requires particular attention; but, in my project, I
> avoided the problem by "disabling" folding, so I didn't care really much
> about that aspect.

That makes sense for your project but it is another case of intrinsics
causing problems for general use.

>>> 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.  :(
>
> It is just only an idea, but could MI Bundles be profitably employed?

Possibly.  Those didn't exist when I did my work.

>> I wonder if we're at the point of drafting an initial RFC for review.
>
> Uh, this a good question. To be honest, it would the first time for
> me.  For sure, we could start by pinpointing the main problems and
> challenges -- that we identified -- that the employment of intrinsics
> would face.

That's the place to start, I think.  Gather a list of requirements/use
cases along with the challenges we've discussed.  Then it's a matter of
engineering a solution that fulfills the requirements while hitting as
few of the challenges as possible.  Let's start by simply gathering some
lists.  I'll take a quick stab and you and others can add to/edit it.

Requirements
------------
- Convey information not readily available in existing IR constructs to
  very late-stage codegen (after regalloc/scheduling, right through
  asm/object emission)

- Flexible format - it should be as simple as possible to express the
  desired information while minimizing changes to APIs

- Preserve information by default, only drop if explicitly told (I'm
  trying to capture the requirements for your use-case here and this
  differs from IR-level metadata)

- No bifurcation between "well-known"/"built-in" information and things
  added later/locally

- Should not impact compile time excessively (what is "excessive?")

Challenges of using intrinsics and other alternatives
-----------------------------------------------------
- Post-SSA annotation/how to associate intrinsics with
  instructions/registers/types

- Instruction selection fallout (inhibiting folding, etc.)

- Register allocation impacts (extending live ranges, etc.)

- Scheduling challenges (ensuring intrinsics can be found
  post-scheduling, etc.)

- Extending existing constructs (which ones?) requires hard-coding
  aspects of information, reducing flexibility

This is currently rather weasily-worded, because I didn't want to impose
too many restrictions right off the bat.

                  -David