[PATCH] D73078: [VPlan] Use consecutive numbers to print VPValues instead of addresses.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 3 13:44:54 PST 2020


fhahn added a comment.

In D73078#1854151 <https://reviews.llvm.org/D73078#1854151>, @gilr wrote:

> It would indeed be good to improve VPValue printing. Initially, there were only a handful of VPValues so those pointer-based IDs seemed sufficient.
>  Since VPValues are now both more common and optionally have an underlying IR value, retaining names from the underlying IR where available could go a long way w.r.t both readability and relating to the loop being vectorized; This would hopefully cover most VPValues.


Sounds good, printing the name of the underlying value should be quite trivial.

> BTW, VP basic blocks could also retain the name of the corresponding IR basic block.

Sounds good!

> It would also be good to distinguish between "pure" VPValues and VPValues wrapping unnamed IR values (can we somehow retain the latter's enumeration?)

+1. I think we would still need a mechanism like this patch to provide a better numbering for 'pure' VPValues.

For VPValues with unnamed wrapped IR values, I think it should be possible to print the number in the IR ( this will implicitly create an IR slot tracker and number the function on demand). We could use a scheme similar to machine IR and use something like `%ir.`(IR name)  for VPValues with underlying IR values.

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73078





More information about the llvm-commits mailing list