- User Since
- May 24 2016, 7:08 PM (219 w, 3 d)
Jul 22 2016
Sean or David, do you think you could commit the pair of patches for me? I don't yet have commit access so I would appreciate that very much.
Jul 20 2016
Just a couple nits from me.
Jul 18 2016
Jul 15 2016
Fantastic. Sean or David, could one of you commit this for me? It would be much appreciated.
Jul 14 2016
Add a couple notes to the docs and a fixme to a test. We can more thoroughly fix up the docs in a separate patch.
Jul 11 2016
Change patch to use -fprofile-generate to enable IRPGO.
Apologies for the delay.
Sean or David, could one of you please commit this for me, I don't have commit access. Thanks!
Jul 8 2016
Added a flag for controlling the behavior of this. Keeping the name short but informative makes the flag name somewhat weird but just let me know if you have some preference on the naming.
Reduce instrumentation flags to fpgo-train and change profile output file flag to fpgo-train-output.
Jul 6 2016
Jul 5 2016
Jul 1 2016
Don't allow -fpgo-train and -fpgo-apply together. Add -fpgo-train-default-output=* to set the default profile output file.
Jun 29 2016
Jun 28 2016
Jun 20 2016
Scratch that, please ignore my previous comment. My own naivety and an IR file with stale ProfileSummary info in the build was causing the error. This patch does in fact fix the problem when not using IR/bitcode files in that way.
So even after applying this patch, IRMover is still emitting an error. I
believe the root cause of this is that we do a pointer based comparison of
the metadata values. This has worked until now when we have constant values
because we unique them in the IR, but doesn't for the ProfileSummary value
which references another metadata entry. If you could, please take a look
and let me know if I'm seeing things correctly.
May 26 2016
Moved the markTails stuff out of runOnFunction so we don't have to duplicate this when we port to the new PM.
Addressed dcci's comments.