Page MenuHomePhabricator

vivekvpandya (Vivek Pandya)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 30 2015, 11:44 AM (207 w, 1 d)

Recent Activity

Yesterday

vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

Just to note there is related commit https://reviews.llvm.org/rL366557.

Fri, Jul 19, 5:15 AM · Restricted Project

Mon, Jul 15

vivekvpandya added inline comments to D60761: [FunctionAttrs] Remove readonly and writeonly assertion.
Mon, Jul 15, 9:36 AM · Restricted Project
vivekvpandya added a comment to D60761: [FunctionAttrs] Remove readonly and writeonly assertion.

This is already accepted. Do you want me to commit this on behalf of you?

Mon, Jul 15, 8:36 AM · Restricted Project

Sun, Jun 23

vivekvpandya added a comment to D53847: [C++2a] P0634r3: Down with typename!.

Minor suggestion, you may want to update http://clang.llvm.org/cxx_status.html page for "typename optional in more contexts" with in this change.

Sun, Jun 23, 11:48 PM · Restricted Project

Jun 19 2019

vivekvpandya committed rL363804: Allow copy/move assignment operator to be coroutine as per N4775.
Allow copy/move assignment operator to be coroutine as per N4775
Jun 19 2019, 7:12 AM
vivekvpandya committed rG3a0100ac30bf: Allow copy/move assignment operator to be coroutine as per N4775 (authored by vivekvpandya).
Allow copy/move assignment operator to be coroutine as per N4775
Jun 19 2019, 7:12 AM
vivekvpandya closed D63381: Allow copy/move assignment operator to be coroutine as per N4775.
Jun 19 2019, 7:11 AM · Restricted Project

Jun 18 2019

vivekvpandya added a comment to D63381: Allow copy/move assignment operator to be coroutine as per N4775.

Ping!

Jun 18 2019, 4:59 AM · Restricted Project

Jun 15 2019

vivekvpandya created D63381: Allow copy/move assignment operator to be coroutine as per N4775.
Jun 15 2019, 11:07 AM · Restricted Project
vivekvpandya updated subscribers of D63381: Allow copy/move assignment operator to be coroutine as per N4775.
Jun 15 2019, 11:07 AM · Restricted Project

Jun 9 2019

vivekvpandya committed rG11cb15f8ed37: Do not derive no-recurse attribute if function does not have exact definition. (authored by vivekvpandya).
Do not derive no-recurse attribute if function does not have exact definition.
Jun 9 2019, 9:15 PM
vivekvpandya committed rL362918: Do not derive no-recurse attribute if function does not have exact definition..
Do not derive no-recurse attribute if function does not have exact definition.
Jun 9 2019, 9:15 PM
vivekvpandya closed D63045: Do not derive no-recurse attribute if function does not have exact definition..
Jun 9 2019, 9:15 PM · Restricted Project

Jun 8 2019

vivekvpandya added a comment to D63045: Do not derive no-recurse attribute if function does not have exact definition..

LGTM. Though I hope to remove the FunctionAttr code soonish.

Jun 8 2019, 8:44 AM · Restricted Project
vivekvpandya created D63045: Do not derive no-recurse attribute if function does not have exact definition..
Jun 8 2019, 4:15 AM · Restricted Project

Jul 24 2018

vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

Coge change looks good but I have few questions on lit test cases.

  1. in llvm/test/CodeGen/PowerPC/ipra-odr.ll IPRA is not called on bar() then it should follow calling convention so in foo() why registers are getting restored between calls to bar() because without IPRA bar() is expected to save callee-saved-registers as per ABI.
  2. llvm/test/CodeGen/X86/ipra-external-linkage.ll same question as above applies. As foo() will save callee-saved-registers as per ABI why around foo() call in bar() it should save/restore callee-saved-register.
Jul 24 2018, 10:31 AM · Restricted Project

Jul 3 2018

vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

@vivekvpandya You're right - the change will allow noCSROpt to run on functions with external linkage, which is not correct.
I think what we really want here is the isSafeForNoCSROpt to check for the existing conditions (i.e., prior to this patch, when it looks for local linkage) and also whether IPRA was successful for this function. I added the isDefinitionExact() call, to try and replicate the necessary conditions for IPRA, but now I'm wondering if it would be better to query the PRUI and make sure it contains a valid RegMask for the given function. Does this seem reasonable to you?

Jul 3 2018, 10:16 PM · Restricted Project

Jun 10 2018

vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

@kbarton can you please validate below tablel?

Jun 10 2018, 10:25 AM · Restricted Project

May 1 2018

vivekvpandya resigned from D46315: [RegUsageInfoCollector] Fix handling of callee saved registers with CSR optimization..

I don't understand if this change address any correctness issue. If this in response to recent test failures you discovered for SystemZ then I think those tests are failing because SystemZ::determineCalleeSaves() did not do job as per expectation. Also your proposed change uses getCalleeSavedRegs() and it adds a loop however previous change is using getCallPreservedMask() which is faster.
It is better to get this reviewed from more experience person in register allocation.

May 1 2018, 11:28 AM
vivekvpandya added reviewers for D46315: [RegUsageInfoCollector] Fix handling of callee saved registers with CSR optimization.: qcolombet, MatzeB.
May 1 2018, 10:30 AM
vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

With this patch, any called function which is not "definition exact" keeps the unmodified regmask on the call instruction, which assumes that the callee saved registers are saved if modified by callee.

I therefore think the check !F.hasLocalLinkage() in isSafeForNoCSROpt() should be replaced with !F.isDefinitionExact(), since the former check only covers a subset of the second one.

Otherwise, the saving of the CSRs might be skipped without this being reflected in the call regmask in caller, right?

May 1 2018, 8:57 AM · Restricted Project

Apr 30 2018

vivekvpandya added a comment to D46232: [SystemZ, IPRA] determineCalleeSaves must always add return register and DP..

But we do not want to force use of a frame pointer, in general this just reduces performance for no reason on Z. Some functions require a frame pointer (those that do dynamic allocas), but most do not.

Apr 30 2018, 11:08 AM
vivekvpandya added inline comments to D46232: [SystemZ, IPRA] determineCalleeSaves must always add return register and DP..
Apr 30 2018, 10:26 AM
vivekvpandya added a comment to D46232: [SystemZ, IPRA] determineCalleeSaves must always add return register and DP..

I run ipra-02.ll with --enable-ipra option with lldb the contorl reaches to SystemZFrameLowering::determineCalleeSaves() through https://github.com/llvm-mirror/llvm/blob/5b508199fa870516e29b847b8af2f85887e05d56/lib/CodeGen/PrologEpilogInserter.cpp#L525
for both functions HasFP is set to false that is why determineCalleeSaves() does not add R11. Can you please verify this?

Apr 30 2018, 10:21 AM
vivekvpandya added inline comments to D46232: [SystemZ, IPRA] determineCalleeSaves must always add return register and DP..
Apr 30 2018, 3:29 AM

Apr 29 2018

vivekvpandya added a comment to D46232: [SystemZ, IPRA] determineCalleeSaves must always add return register and DP..

When enabling IPRA on SystemZ, a benchmark crashed and I found out that a function had been optimized to not save the Callee Saved Registers, which unfortunately included the return register (%r14) on SystemZ, so when the function tried to return UB resulted.

Apr 29 2018, 6:39 AM

Apr 18 2018

vivekvpandya added a comment to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

Change looks good to me. But please fix the new test case as suggested by @nemanjai
In this new test do you see improvement in register allocation due to IPRA? If test-case does not show any benefit due to IPRA then it is not suitable test for this patch.
Also I hope this patch is also tested with other architecture which have LIT based test-cases for IPRA. It is very unlikely that such test-case will have function with linkage type which return true for isInterposableLinkage() but if such case is there then this change may break such tests.

Apr 18 2018, 10:46 AM · Restricted Project

Apr 7 2018

vivekvpandya resigned from D45378: [InstCombine] Propagate null values from conditions to other basic blocks.

I am not an expert for InstCombine. But I think @spatel has worked on it for long time so I think he is appropriate person to review this.

Apr 7 2018, 9:52 AM

Mar 19 2018

vivekvpandya added a comment to D44067: [LV] Improving "Control-Flow-Select" Vectorization remark..

There are a few issues with formatting (trailing spaces, using tabs, lines > 80 chars, see https://llvm.org/docs/CodingStandards.html). Could you use clang-format to format the diff?

Mar 19 2018, 10:42 AM

Mar 17 2018

vivekvpandya added a comment to D44066: Addition in Auto Vectorization Cost-Model Remark.

In first pass of the review I did not pay attention to logic in this change, but I think this change is not required because as per my understanding from the code the best cost of vectorization is already calculated by the code, when vectorization is not beneficial it just not generating optimization remark, but if when vectorization is forced by user it does print this information in debug output statements. I am referring DEBUG(if (ForceVectorization && Width > 1 && Cost >= ScalarCost).

Mar 17 2018, 10:37 AM
vivekvpandya added a comment to D44067: [LV] Improving "Control-Flow-Select" Vectorization remark..

Is there any bug reported for this? if yes then please mention that.

Well if there is no bug reported for this then do you have any motivating example or other community member has suggested this improvement?

Mar 17 2018, 1:26 AM

Mar 16 2018

vivekvpandya added inline comments to D44066: Addition in Auto Vectorization Cost-Model Remark.
Mar 16 2018, 3:57 AM
vivekvpandya added reviewers for D44066: Addition in Auto Vectorization Cost-Model Remark: nadav, anemet.

Final looks good or rejection should be given by community member which have more experience with LoopVectorizer. Adding @nadav , @anemet.

Mar 16 2018, 3:40 AM
vivekvpandya added a comment to D44067: [LV] Improving "Control-Flow-Select" Vectorization remark..

Few high level comments from my side. For more accurate review I recommend wait until @anemet takes loot at it :)

Mar 16 2018, 2:18 AM

Feb 4 2018

Herald updated subscribers of D26723: [optview] added C++ version of opt-viewer.
Feb 4 2018, 1:46 AM

Oct 11 2017

vivekvpandya committed rL315476: [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closure.
[NFC] Convert OptimizationRemarkEmitter old emit() calls to new closure
Oct 11 2017, 10:13 AM
vivekvpandya closed D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls by committing rL315476: [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closure.
Oct 11 2017, 10:13 AM

Oct 10 2017

vivekvpandya updated the diff for D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls.

updated

Oct 10 2017, 7:05 PM

Oct 8 2017

vivekvpandya updated the diff for D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls.

Updated patch to address @anemet 's comment.

Oct 8 2017, 6:44 AM

Oct 3 2017

vivekvpandya updated subscribers of D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls.
Oct 3 2017, 8:24 PM
vivekvpandya updated the diff for D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls.

changes Clang-formated!

Oct 3 2017, 11:57 AM

Sep 26 2017

vivekvpandya created D38285: Convert OptimizationRemarkEmitter old emit() calls to new closure parameterized emit() calls.
Sep 26 2017, 3:30 PM

Sep 15 2017

vivekvpandya committed rL313390: This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 .
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352
Sep 15 2017, 1:11 PM
vivekvpandya committed rL313389: This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 LLVM code change….
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 LLVM code change…
Sep 15 2017, 1:11 PM
vivekvpandya committed rL313387: This reverts r313381.
This reverts r313381
Sep 15 2017, 12:55 PM
vivekvpandya committed rL313382: This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352 .
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=32352
Sep 15 2017, 12:32 PM

Sep 13 2017

vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Added method to detach unique_ptr<DiagnosticHandler> from LLVMContext.

Sep 13 2017, 11:50 AM
vivekvpandya updated the diff for D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

update

Sep 13 2017, 11:48 AM

Sep 12 2017

vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Update.

Sep 12 2017, 11:24 AM
vivekvpandya added a comment to D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Why? That was inside BackendConsumer.

Sep 12 2017, 11:21 AM

Sep 11 2017

vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
Sep 11 2017, 11:36 AM
vivekvpandya updated the diff for D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Update

Sep 11 2017, 11:35 AM
vivekvpandya added inline comments to D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
Sep 11 2017, 11:34 AM

Sep 8 2017

vivekvpandya updated the summary of D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
Sep 8 2017, 10:05 AM
vivekvpandya added a comment to D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

@anemet if this looks oky to you then I can commit this on weekend.

Sep 8 2017, 9:55 AM

Sep 6 2017

vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Test Updated

Sep 6 2017, 10:16 AM

Sep 5 2017

vivekvpandya updated the diff for D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Clang-formated

Sep 5 2017, 10:09 AM
vivekvpandya added a comment to D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

You also need to add a test. You should be able to extend either the LICM's or the Vectorizer's test to also get the remarks due to allowExtraAnalysis with -pass-remarks not just with -pass-remarks-output.

Sep 5 2017, 10:05 AM
vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Updated the patch , tests will be updated in next patch.

Sep 5 2017, 10:05 AM

Aug 31 2017

vivekvpandya updated the diff for D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Updated the patch! I don't think now we require to save OldDiagnosticHandler and context as we have ClangDiagnosticHandler class with creation of CreateASTConsumer, but I need some review.

Aug 31 2017, 11:06 AM
vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Updated the patch!

Aug 31 2017, 11:03 AM

Aug 27 2017

vivekvpandya created D37196: [Clang] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
Aug 27 2017, 8:59 AM
vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Update the patch.

Aug 27 2017, 8:57 AM

Jul 31 2017

vivekvpandya added inline comments to D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
Jul 31 2017, 9:54 AM

Jul 26 2017

vivekvpandya updated the diff for D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.

Updated the patch but some cleanup is still to be done. For now I am focusing on correctness.

Jul 26 2017, 8:32 AM

Jun 6 2017

vivekvpandya committed rL304779: .
Jun 6 2017, 1:17 AM
vivekvpandya closed D32304: Reduce printing values with default in MIR based codegen testing YAML by committing rL304779: .
Jun 6 2017, 1:17 AM

Jun 5 2017

vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

@MatzeB sorry for the delay I was on vacation. I have updated the patch as per your suggestion. Due to GlobalIsel related work some test cases have some updates frequently so it is better to close this as earliest as possible.

Jun 5 2017, 11:51 AM

May 24 2017

vivekvpandya created D33514: [WIP] Bug 32352 - Provide a way for OptimizationRemarkEmitter::allowExtraAnalysis to check if (specific) remarks are enabled.
May 24 2017, 12:05 PM
vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

Ping!

May 24 2017, 11:42 AM

May 18 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

ping!

May 18 2017, 10:12 PM

May 15 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

In previous patch constant used to set default value for object property of type int64_t , uint64_t was not portable.
Due to

if (!SimplifyMIR)
      Out.setWriteDefaultValues(true);

some test cases need to be updated. Sorry previously I didn't run llvm-lit on whole test folder.

I don't understand this explanation. Can you give some example? It feels odd that you had to add -simplify-mir to all of those tests...

If we make YAML:IO to write default values it will print every things including empty strings, for example consider test/CodeGen/X86/virtual-registers*.ll in that if we don't use -simplify-mir it will generate - { reg: '%edi', virtual-reg: '' } which makes POST-RA-NEXT check failed. This is why I have added -simplify-mir where required.
However in test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll I think adding -simplify-mir is not correct because it also removes basic block printing and for that particular case it is required that only one successor is present after certain statement so for that case I need to add fields which were not getting printed before but now they are getting printed.
Also before this patch we already do not print string with empty value so all these test-cases have been written in such manner that check for filed with empty string is not done so to preserve that I added -simplify-mir. Or we need to other way around.

May 15 2017, 11:35 AM
vivekvpandya requested review of D32304: Reduce printing values with default in MIR based codegen testing YAML.
May 15 2017, 7:28 AM

May 14 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

Also is there any way to test patch on build bot with out committing changes specially on different hardware?

May 14 2017, 6:37 AM
vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

In previous patch constant used to set default value for object property of type int64_t , uint64_t was not portable.
Due to

May 14 2017, 6:36 AM

May 13 2017

vivekvpandya reopened D32304: Reduce printing values with default in MIR based codegen testing YAML.
May 13 2017, 4:30 AM
vivekvpandya committed rL302985: This reverts r302984.
This reverts r302984
May 13 2017, 4:12 AM
vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

This appears to have broken MANY buildbots due to some compilation error that I haven't really looked at. I'll wait a bit longer to see if you (@vivekvpandya) pull it out/fix it and if it doesn't happen soon, I'll probably just pull it out.

May 13 2017, 4:10 AM
vivekvpandya committed rL302984: Simplify MIR Output used for Codegen Testing.
Simplify MIR Output used for Codegen Testing
May 13 2017, 2:09 AM
vivekvpandya closed D32304: Reduce printing values with default in MIR based codegen testing YAML by committing rL302984: Simplify MIR Output used for Codegen Testing.
May 13 2017, 2:09 AM

May 11 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

I don't have commit access. Kindly commit it. Sorry for the trouble.

May 11 2017, 10:53 AM
vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

ping!

May 11 2017, 7:43 AM

May 6 2017

vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

-simplify-mir is not true by default so there is no need to change mir test cases which were modified previously.

May 6 2017, 12:27 PM

May 3 2017

vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

Update the patch as per discussion.

May 3 2017, 1:07 PM

May 1 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

Hi guys,

Hello @qcolombet

I am not sure I like the approach.
I agree that as a human the among of MIR we need to write to make it work should be minimal. However, I believe the printer should be as dumb as possible. Printing is cheap and also, anytime the default changes, the printed output would still work.

I am new to this thing but I would like to have my input from what ever I have understood till now.
I think not printing entities which have default value is useful when someone wants to write a new MIR test file by starting with llc generating a initial version, adding required check statements and other commands to it.
Also if someone prefers to have default values printed then we can provide a flag in llc that will map to WriteDefaultValues in YAMLTraits ( as llvm-pdbdump tool does it currently).
After having quick look at MIRParser I feel that with syntactically correct YAML it will create MachineFunction , entities which are missing from YAML input will have default value.
If default value changes then printer will just print it (as it may not be updated in MIRYAMLMapping.h ) but nothing will break.
I feel that challenges with default value will come when it is not possible to get default value for some target specific entity.

May 1 2017, 9:05 AM

Apr 28 2017

vivekvpandya requested review of D32304: Reduce printing values with default in MIR based codegen testing YAML.
Apr 28 2017, 12:42 PM
vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

Hi Matthias,

Apr 28 2017, 12:42 PM

Apr 27 2017

vivekvpandya added a comment to D32304: Reduce printing values with default in MIR based codegen testing YAML.

Ok I will update this for all optional mapping and then do testing on existing mir test files in various target folders.

Apr 27 2017, 9:47 PM

Apr 25 2017

vivekvpandya planned changes to D32304: Reduce printing values with default in MIR based codegen testing YAML.
Apr 25 2017, 11:04 AM
vivekvpandya updated the diff for D32304: Reduce printing values with default in MIR based codegen testing YAML.

As YAML will first process frameInfo object so it is not easy to remove "frameInfo" from output after finding it's empty. However if we provide default value for frameInfo mapping in MachineFunction class then we can eliminate it from output if entire frameInfo is having default value. So I have update the patch accordingly. If this approach seems good then I can send updated patch for all option mapping.

Apr 25 2017, 11:03 AM

Apr 21 2017

vivekvpandya updated the summary of D32304: Reduce printing values with default in MIR based codegen testing YAML.
Apr 21 2017, 9:46 AM

Apr 20 2017

vivekvpandya created D32304: Reduce printing values with default in MIR based codegen testing YAML.
Apr 20 2017, 11:14 AM

Oct 18 2016

vivekvpandya abandoned D23980: Documentation for IPRA.
Oct 18 2016, 10:31 AM

Sep 2 2016

vivekvpandya added a comment to D23980: Documentation for IPRA.

ping !

Sep 2 2016, 8:22 AM

Aug 28 2016

vivekvpandya retitled D23980: Documentation for IPRA from to Documentation for IPRA.
Aug 28 2016, 9:19 PM

Jul 20 2016

vivekvpandya added a comment to D22400: Fix RegMask calculation for alias registers.

Sorry @MatzeB I don't have commit access. Usually @mehdi_amini commits for me. If you are not able to find time I guess @mehdi_amini will do before this week ends.

Jul 20 2016, 8:43 PM

Jul 18 2016

vivekvpandya added a comment to D22400: Fix RegMask calculation for alias registers.

ping !

Jul 18 2016, 10:38 AM

Jul 17 2016

vivekvpandya added a comment to D21003: Fix mentor name.

@gareevroman I don't have commit access. But I believe if we want to manage this page after GSoC 2016 (at least I want) to help other GSoC aspirant it is good to have commit access for me ( or at least 2 people who want to mange this page) so that every time we don't have to disturb you : ) . @grosser sir do you have any suggestion here?

Jul 17 2016, 5:01 AM
vivekvpandya added a comment to D21003: Fix mentor name.

@mreisinger just check if this requires rebase otherwise @gareevroman will help to commit this.

Jul 17 2016, 4:44 AM

Jul 15 2016

vivekvpandya updated D22400: Fix RegMask calculation for alias registers.
Jul 15 2016, 12:53 AM