[PATCH] D72425: [OptRemark] RFC: Introduce a message table for OptRemarks

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 8 17:10:30 PST 2020


hfinkel added a comment.

In D72425#1811143 <https://reviews.llvm.org/D72425#1811143>, @andrew.w.kaylor wrote:

> In D72425#1811098 <https://reviews.llvm.org/D72425#1811098>, @hfinkel wrote:
>
> > I like this general idea; couple of thoughts...
> >
> > 1. Clang has a similar system, and one disadvantage is that any time you change/add any message, it seems to trigger a large rebuild. Could we have this TG system generate separate .inc files for each category of things, so we don't have the same kind of rebuild problem.
>
>
> Probably. One thing I was imagining coming out of the .td file(s) is an enum somewhere that assigns values to all of the messages. I suppose we could make that multiple enums, each with a fixed starting value to avoid triggering rebuilds. In general, these should lend themselves to logical groupings. We'd probably also want a way for downstream LLVM-based products to painlessly add their own remarks and groups should help with that.
>
> > 2. Given that are arguments are named, can we use something like `"Format string with optional specifier like %{NV}"` instead of `"Format string with optional specifier like %0"`? I think that the former would be better.
>
> Yes, that's a great idea. So, if I understand what you're suggesting, the entry for the remark I used as an example would look like this:
>
>   def remark_gvn_load_elim: OptRemark<"LoadElim", "load of type %Type eliminated", " in favor of %InfavorOfValue">;
>  
>
>
> Is that the idea?


Yep, something like that.


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

https://reviews.llvm.org/D72425





More information about the llvm-commits mailing list