Page MenuHomePhabricator

appcs (Anmol P. Paralkar)
User

Projects

User does not belong to any projects.

User Details

User Since
Dec 14 2016, 10:50 AM (139 w, 4 d)

Recent Activity

Jul 16 2019

appcs added a reviewer for D64830: [Xtensa 4/10] Add basic *td files with Xtensa architecture description.: appcs.
Jul 16 2019, 4:04 PM · Restricted Project
appcs accepted D64829: [Xtensa 3/10] Add initial version of the Xtensa backend..
Jul 16 2019, 4:04 PM · Restricted Project
appcs added a reviewer for D64829: [Xtensa 3/10] Add initial version of the Xtensa backend.: appcs.
Jul 16 2019, 4:00 PM · Restricted Project
appcs added inline comments to D64827: [Xtensa 2/10] Add Xtensa ELF definitions..
Jul 16 2019, 3:59 PM · Restricted Project
appcs added a reviewer for D64827: [Xtensa 2/10] Add Xtensa ELF definitions.: appcs.
Jul 16 2019, 3:57 PM · Restricted Project
appcs accepted D64826: [Xtensa 1/10] Recognize Xtensa in triple parsing code..
Jul 16 2019, 3:57 PM · Restricted Project
appcs added a reviewer for D64826: [Xtensa 1/10] Recognize Xtensa in triple parsing code.: appcs.
Jul 16 2019, 3:51 PM · Restricted Project

Dec 7 2018

appcs added a comment to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..

Thank you @Szelethus for the guidance. Thank you @NoQ for further input. Please see inline:

Dec 7 2018, 3:18 PM

Nov 28 2018

appcs added a comment to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..

ping

Nov 28 2018, 2:41 PM

Nov 1 2018

appcs added a comment to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..

Let's talk about more general topics: Your checker's name is "TimeChecker", not "Y2K38Checker" or something similar, do you have plans on expanding this checker to cover more time.h related functionality?

Nov 1 2018, 4:23 PM
appcs added inline comments to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Nov 1 2018, 10:50 AM
appcs added inline comments to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Nov 1 2018, 10:37 AM

Oct 31 2018

appcs added inline comments to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 31 2018, 3:22 PM
appcs updated the diff for D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..

Incorporated code review feedback; thank you @Szelethus and @george.karpenkov

Oct 31 2018, 3:13 PM

Oct 22 2018

appcs added inline comments to D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 22 2018, 12:16 PM

Oct 11 2018

appcs retitled D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues. from Implement a prototype checker for detecting Year 2038 related issues. to Implement a prototype checker in the Clang Static Analyzer for detecting Year 2038 related issues..
Oct 11 2018, 9:30 PM
appcs updated subscribers of D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:24 PM
appcs abandoned D53124: Register TimeChecker with Clang Static Analyzer.

Re-spun with feedback received into: D53185

Oct 11 2018, 9:22 PM
appcs added a reviewer for D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues.: george.karpenkov.
Oct 11 2018, 9:17 PM
appcs updated the summary of D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:14 PM
appcs updated the summary of D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:14 PM
appcs updated the summary of D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:11 PM
appcs updated the summary of D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:10 PM
appcs added a reviewer for D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues.: Szelethus.

Thank you very much for the feedback. I have added a little functionality to demonstrate the working of a prototype checker for a some sample Y2K38 issues. There are some TODO's in the test files indicative of some subsequent checking that we will add.

Oct 11 2018, 9:10 PM
appcs created D53185: [analyzer] Implement a prototype checker for detecting Year 2038 related issues..
Oct 11 2018, 9:03 PM

Oct 10 2018

appcs created D53124: Register TimeChecker with Clang Static Analyzer.
Oct 10 2018, 8:18 PM

Jan 19 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Thank you, everybody, for the valuable inputs.

Jan 19 2017, 11:12 AM

Jan 13 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

There are several options I could think of:
Either surfacing it through a driver option, enabling it at -Og, or benchmarking it and arguing to enable it by default at some optimization settings.

Jan 13 2017, 7:09 PM
appcs updated the diff for D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.
  • Added documentation to source code on -mergefunc-preserve-debug-info behaviour and noted the difference from the base -mergefunc
  • Elaborated & consolidated comments in regards MergeFunctionsPDI for MergeFunctions::writeThunk()
  • Made suggested stylistic changes.
Jan 13 2017, 7:06 PM

Jan 12 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Added some more stylistic changes.

Jan 12 2017, 4:51 PM

Jan 11 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Is this good?

Jan 11 2017, 7:56 AM

Jan 6 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Submitting ticked off items.

Jan 6 2017, 8:59 PM
appcs updated the diff for D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Under -mergefunc-preserve-debug-info

  • A thunk's call site is preserved to point to the thunk when both occur within the same translation unit.
Jan 6 2017, 8:50 PM
appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.
What should -mergefunc-preserve-debug-info do about the thunk's call to the shared implementation?
Mark as tail call or not? The existing -mergefunc behaviour is to mark it as a tail call. We could leave it as is,
unless someone specifically asks for a change under -mergefunc-preserve-debug-info; would that be OK?

I think marking it as a tail call makes most sense.

Jan 6 2017, 1:59 PM
appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Call sites of the merged function occurring from within the TU of the merged function's definition will point directly to the shared implementation and call sites of the merged function that are external to the TU of the merged function's definition call the thunk for the merged function (which tail call's the shared implementation passing forward the incoming arguments). This is existing behaviour under -mergefunc and remains unchanged under -mergefunc-preserve-debug-info (except for the tail call part).

Is this the right thing to do, though? I would think that for better debugability users would always prefer the version with the thunk even in the current TU. Then again, subsequent optimization passes would likely inline the thunk and thus potentially undo most of the effect. Have you experimented with this variant? Would the debug info from the thunk survive?

Thank you; I agree that this greatly enhances the debug experience. Automatically modifying the call site with a direct call to the shared implementation instead of (what is now) the thunk, when within the TU, is confusing when debugging. Stepping into the thunk from the call site and from within the thunk, into the shared implementation keeps the debug experience uniform for internal and external call sites of functions that become thunks. (If you ask me, this is similar in spirit to not marking the thunk's call to the shared implementation as a tail call to help debugging - the full back trace is the same in both cases and otherwise, there is a certain element of surprise in both cases. Basically, we are saying that under -mergefunc-preserve-debug-info we trade off optimization partly (at -O0) to aid debugability, modifying the transformation slightly, to make the execution flow explicit).

Yes. I think this is the right approach. When using -mergefunc-preserve-debug-info we should always call the thunk even in the same TU.

Jan 6 2017, 10:11 AM

Jan 5 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.

Call sites of the merged function occurring from within the TU of the merged function's definition will point directly to the shared implementation and call sites of the merged function that are external to the TU of the merged function's definition call the thunk for the merged function (which tail call's the shared implementation passing forward the incoming arguments). This is existing behaviour under -mergefunc and remains unchanged under -mergefunc-preserve-debug-info (except for the tail call part).

Is this the right thing to do, though? I would think that for better debugability users would always prefer the version with the thunk even in the current TU. Then again, subsequent optimization passes would likely inline the thunk and thus potentially undo most of the effect. Have you experimented with this variant? Would the debug info from the thunk survive?

Jan 5 2017, 6:21 PM

Jan 4 2017

appcs added a comment to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.
Thank you for your review, Adrian.
Jan 4 2017, 4:52 PM

Jan 3 2017

appcs added inline comments to D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.
Jan 3 2017, 3:37 PM

Dec 22 2016

appcs retitled D28075: MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info from to MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info.
Dec 22 2016, 7:41 PM

Dec 14 2016

appcs added a comment to D22051: MergeSimilarFunctions: a code size pass to merge functions with small differences.

MergeSimilarFunctions demonstrates great improvement on Cisco software, so this is of great value to us. We have some improvements upon the base work to improve the compile time.

Dec 14 2016, 11:17 AM