[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