[llvm-dev] The state of IRPGO (3 remaining work items)

Dean Michael Berris via llvm-dev llvm-dev at lists.llvm.org
Sun Jun 26 21:39:23 PDT 2016

On Fri, Jun 24, 2016 at 1:44 AM Eric Christopher via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Thu, Jun 2, 2016, 6:41 PM Xinliang David Li via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> Sounds fine to me, though I am not a fan of using unstable in the option.
>> I think a more meaningful way (that capture the essence of the difference)
>> is the following naming:
>> 1) FEPGO:  -fprofile-instr-generate=source or
>> -fprofile-instr-generate=region
>> 2) IR: -fprofile-instr-generate=cfg or -fprofile-instr-generate=graph
>> Also since -fprofile-instr-generate= form is already used to specify raw
>> profile path, we may need a different driver option. Alternatives include
>> 1) -fprofile-instrument=<...> -- this maps directly to the cc1 option we
>> have today
>> or
>> 2) -fpgo-instr=<> -- suggested by Fred or
>> 3) -fpgo-instr-method=<...>
> Random bikeshedding. I like fprofile-instrument because it merges a lot of
> similar ideas behind instrumenting - and oddly enough what I was suggesting
> in the x-ray thread before seeing this.
+1 to -fprofile-instrument=... (as someone working on the XRay stuff, I'd
much rather have less flags, and consolidate a lot of these similar things
into a more inclusive flag).

I would even make it shorter, and say -finstrument={profile-..., xray-...}
so we can have multiple "namespaced" values for -finstrument=.

Just my A$0.02.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160627/5b678449/attachment.html>

More information about the llvm-dev mailing list