This is an archive of the discontinued LLVM Phabricator instance.

Add support for multiple prof metadata on instructions.
AbandonedPublic

Authored by hjyamauchi on Oct 2 2017, 11:49 AM.

Details

Summary

An instruction can currently have up to one prof metadata type associated with
it. It's useful to be able to have more than one prof metadata associated with
an instruction, going forward.

This patch introduces an optional two-level structure in addition to the current
single-level one. For example,

br i1 %cond, label %then, label %else, !prof !0

!0 = !{!"branch_weights", i32 64, i32 4} ; Single-level

br i1 %cond, label %then, label %else, !prof !1

!1 = !{!1, !2, !3, !4} ; Two-level
!2 = !{!"branch_weights", i32 64, i32 4}
!3 = !{!"foo"}
!4 = !{!"bar"}

Event Timeline

hjyamauchi created this revision.Oct 2 2017, 11:49 AM
hjyamauchi updated this revision to Diff 117451.Oct 2 2017, 4:43 PM

A bit of cleanup and added an assert.

davidxl edited edge metadata.Oct 6 2017, 9:46 AM

This does not look like backward compatible IR change. For the purpose of annotating irreducible loop headers, it might be better to introduce a new type of metadata.

This does not look like backward compatible IR change. For the purpose of annotating irreducible loop headers, it might be better to introduce a new type of metadata.

The current single-level format is still used when there's only one prof metadata per instruction. The two-level format is used only when there are multiple items.

So, it should be backward compatible in that sense at least.

To give more context, the motivating issue for us is the block frequency propagation of irreducible loops under PGO.

We think that if we can annotate irreducible loop headers with (relative) frequency weights (based on PGO profiles), that could work.

That would need a new annotation type in the form of, either

(1) a new (sub)type of prof metadata,

OR

(2) a new metadata type (a new MD_xxx).

We aren't sure which would be better.

A rationale for (1) is that it can be considered as a type of "prof" annotation as it's based on profile data.

This patch assumes (1) because our current idea is to put the annotation on the terminator of a header block where there is likely a branch_weight prof metadata on it (hence the support for multiple prof metadata.)

Alternatively (2) would not need this patch.

hjyamauchi abandoned this revision.Dec 7 2017, 2:56 PM