mgrang (Mandeep Singh Grang)
http://livgently.com

Projects

User does not belong to any projects.

User Details

User Since
Jan 28 2015, 2:26 PM (177 w, 4 d)

Recent Activity

Wed, Jun 13

mgrang committed rC334639: [COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl.
[COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl
Wed, Jun 13, 11:54 AM
mgrang committed rL334639: [COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl.
[COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl
Wed, Jun 13, 11:54 AM
mgrang closed D48132: [COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl.
Wed, Jun 13, 11:54 AM
mgrang created D48132: [COFF] Add ARM64 intrinsics: __yield, __wfe, __wfi, __sev, __sevl.
Wed, Jun 13, 9:32 AM

Wed, May 30

mgrang added inline comments to D46653: Start support for linking object files with split stacks.
Wed, May 30, 6:37 PM

Tue, May 29

mgrang added inline comments to D47511: [AMDGPU] Construct memory clauses before RA.
Tue, May 29, 8:54 PM
mgrang added inline comments to D47474: Implement cpu_dispatch/cpu_specific Multiversioning.
Tue, May 29, 1:53 PM

May 24 2018

mgrang added inline comments to D47329: [llvm-exegesis] Analysis: Display idealized sched class port pressure..
May 24 2018, 8:05 AM

May 23 2018

mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.

This is merged in rL333137.

May 23 2018, 5:21 PM
mgrang committed rL333137: [RISCV] Lower the tail pseudoinstruction.
[RISCV] Lower the tail pseudoinstruction
May 23 2018, 3:51 PM
mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.

Thanks for the pointer Alex. I guess what I was doing incorrect was specifying GPRTC as the reg class in the PseudoInstExpansion which made the tablegen trip.

May 23 2018, 1:24 PM
mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.

Added a PseudoInstExpansion rule for PseudoTAILIndirect as per Alex's suggestion.

May 23 2018, 1:22 PM
mgrang accepted D46822: [RISCV] Add driver for riscv32-unknown-elf baremetal target.

LGTM.

May 23 2018, 10:52 AM

May 22 2018

mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.
  1. Lowered PseudoTAILIndirect in AsmPrinter (similar to AArch64 TCRETURNri pseudo).
  2. Added test cases for tail call on external symbols and indirect tail call.
  3. Addressed other comments.
May 22 2018, 1:38 PM
mgrang added inline comments to D47196: [Time-report ](2): Recursive timers in Clang.
May 22 2018, 10:52 AM

May 19 2018

mgrang added inline comments to D43962: [GlobalISel][utils] Adding the init version of Instruction Select Testgen.
May 19 2018, 11:26 PM

May 18 2018

mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.
In D45395#1102983, @asb wrote:

I'm definitely seeing failures with this due to PseudoTAILIndirect.

Sorry for being cryptic regarding handling of PseudoTAILIndirect. I meant it should have no asmstring because it should never reach the asm printer. It perhaps would be nice if there was an assert if an isCodeGenOnly instruction makes it through to the asm printer.

PseudoTAILIndirect is purely a codegen construct, and won't produce the tail pseudoinstruction. My first instinct would be to handle it very similarly to PseudoCALLIndirect and use PseudoInstExpansion:

def PseudoTAILIndirect : Pseudo<(outs), (ins GPRTC:$rs1), [(Tail GPRTC:$rs1)]>,
                         PseudoInstExpansion<(JALR X0, GPR:$rs1, 0)>;

But I see there's some sort of issue there and haven't had a chance yet to dig deep into what's going on. Setting let usesCustomInserter and handling in EmitInstrWithCustomerInserter is an alternative approach that comes to mind, though it would be good to better understand the PseudoInstExpansion issue first.

Test-wise, we definitely need coverage of PseudoInstExpansion. Beyond that, this seems like a nice optimisation to have. You mentioned it made not much difference in the workloads you threw at it, but it seems to trigger quite frequently in the sort of small test programs you find in a compiler test suite. If nothing else, it helps reduce the amount of code to look through when debugging those sort of inputs :)

May 18 2018, 5:20 PM

May 17 2018

mgrang committed rL332634: [RISCV] Implement MC layer support for the tail pseudoinstruction.
[RISCV] Implement MC layer support for the tail pseudoinstruction
May 17 2018, 10:35 AM
mgrang closed D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 17 2018, 10:35 AM

May 15 2018

mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.

Addressed comments.

May 15 2018, 6:24 PM
mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.

Thanks for the comments Alex. I had a couple of observations:

May 15 2018, 1:45 PM

May 14 2018

mgrang added inline comments to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 14 2018, 1:11 PM
mgrang added inline comments to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 14 2018, 12:55 PM
mgrang updated the diff for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.

Addressed comments.

May 14 2018, 12:53 PM

May 10 2018

mgrang accepted D46182: [RISCV] Set isReMaterializable on ADDI and LUI instructions.

LGTM. I didn't get a chance to look further into this. Since this patch helps with overall code size I think we can commit this now and we can report back once we have done more analysis.

May 10 2018, 8:02 AM

May 8 2018

mgrang accepted D46619: Remove 'abi-breaking-checks' lit feature..

LGTM. r311730 was initially based on ABI_BREAKING_CHECKS but according to review comments, it seemed better w/o that check. So abi-breaking ended up being never used. I think we can safely remove this.

May 8 2018, 6:52 PM

May 3 2018

mgrang added inline comments to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 3 2018, 12:05 PM
mgrang added inline comments to D45395: [RISCV] Lower the tail pseudoinstruction.
May 3 2018, 12:03 PM
mgrang updated the diff for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 3 2018, 12:03 PM
mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.

Thanks Alex for the explanation on indirect parameter passing. I have updated the condition in my patch and added a unit test.

May 3 2018, 12:02 PM
mgrang added inline comments to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 3 2018, 11:59 AM
mgrang updated the diff for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.

Thanks Alex for the explanation on indirect parameter passing. I have updated the condition in my patch and added a unit test.

May 3 2018, 11:55 AM

May 2 2018

mgrang retitled D45395: [RISCV] Lower the tail pseudoinstruction from [RISCV] Lower the tail pseudo instruction to [RISCV] Lower the tail pseudoinstruction.
May 2 2018, 1:17 PM
mgrang added a dependency for D45395: [RISCV] Lower the tail pseudoinstruction: D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 2 2018, 1:15 PM
mgrang removed a dependency for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction: D45395: [RISCV] Lower the tail pseudoinstruction.
May 2 2018, 1:15 PM
mgrang added a dependent revision for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction: D45395: [RISCV] Lower the tail pseudoinstruction.
May 2 2018, 1:15 PM
mgrang removed a dependent revision for D45395: [RISCV] Lower the tail pseudoinstruction: D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 2 2018, 1:15 PM
mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.
May 2 2018, 1:15 PM
mgrang updated the diff for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
May 2 2018, 1:11 PM
mgrang added a comment to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.

Thanks for your comments @asb. There seems to be some problem with long double function arguments which I wanted to clarify.

May 2 2018, 10:44 AM

Apr 27 2018

mgrang updated the summary of D45395: [RISCV] Lower the tail pseudoinstruction.
Apr 27 2018, 5:13 PM
mgrang added a dependency for D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction: D45395: [RISCV] Lower the tail pseudoinstruction.
Apr 27 2018, 5:12 PM
mgrang added a comment to D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.

Here's the patch to generate tail pseudo instruction: https://reviews.llvm.org/D45395

Apr 27 2018, 5:12 PM
mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.

Here's the MC layer patch which lower tail pseudo to auipc and jalr: https://reviews.llvm.org/D46221

Apr 27 2018, 5:12 PM
mgrang added a dependent revision for D45395: [RISCV] Lower the tail pseudoinstruction: D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
Apr 27 2018, 5:12 PM
mgrang created D46221: [RISCV] Implement MC layer support for the tail pseudoinstruction.
Apr 27 2018, 5:12 PM
mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.

Addressed comments and split the MC part into a separate patch.

Apr 27 2018, 5:04 PM
mgrang added a comment to D46182: [RISCV] Set isReMaterializable on ADDI and LUI instructions.
In D46182#1081552, @asb wrote:

@asb Thanks for the patch. I tested this on our internal workload and it gave us ~44 bytes savings.
However, instead if we mark all ALU insts as isReMaterializable then we get ~226 bytes savings:
Note: Marking ALU insts in addition to ADDI and LUI as isReMaterializable still gave us only ~44 bytes savings.

Hi Mandeep - thanks for taking a look. I'm a bit confused, which of the above 3 statements is true?

Apr 27 2018, 1:30 PM
mgrang added a comment to D46182: [RISCV] Set isReMaterializable on ADDI and LUI instructions.

@asb Thanks for the patch. I tested this on our internal workload and it gave us ~44 bytes savings. However, instead if we mark all ALU insts as isReMaterializable then we get ~226 bytes savings:

Apr 27 2018, 12:23 PM

Apr 25 2018

mgrang updated the diff for D45395: [RISCV] Lower the tail pseudoinstruction.

Rebased patch on top of D44885.

Apr 25 2018, 6:16 PM
mgrang added a comment to D45395: [RISCV] Lower the tail pseudoinstruction.
In D45395#1076818, @asb wrote:

It looks like this must be applied on top of D44885. Could you please rebase on to the latest version of that patch? It would also be useful to use 'Edit Related Revisions...' to indicate the in-flight patch(es) that this depends on.

Apr 25 2018, 1:15 PM

Apr 24 2018

mgrang added a comment to D44885: [RISCV] Expand function call to "call" pseudoinstruction.

@shiva0217 Could you please rebase and commit this patch? My tail call patch D45395 depends on this patch.

Apr 24 2018, 6:10 PM
mgrang added a dependency for D45395: [RISCV] Lower the tail pseudoinstruction: D44885: [RISCV] Expand function call to "call" pseudoinstruction.
Apr 24 2018, 6:05 PM
mgrang added a dependent revision for D44885: [RISCV] Expand function call to "call" pseudoinstruction: D45395: [RISCV] Lower the tail pseudoinstruction.
Apr 24 2018, 6:05 PM
mgrang committed rL330773: [docs] Add a note on non-deterministic sorting order of equal elements.
[docs] Add a note on non-deterministic sorting order of equal elements
Apr 24 2018, 2:29 PM
mgrang closed D45831: [docs] Add a note on non-deterministic sorting order of equal elements.
Apr 24 2018, 2:29 PM
mgrang added a comment to D45831: [docs] Add a note on non-deterministic sorting order of equal elements.

Reviewers, if you do not have any problem with the wording of the note I would like to commit this.

Apr 24 2018, 11:14 AM
mgrang added a comment to D45858: [DivRemPairs] Fix non-determinism in use list order..

That looks ok, but I'm curious;

  1. How do you discover this problem?

I ran into this when testing a totally unrelated change that I expected to have no effect on final code generation. When it generated different code for one llvm-test-suite test case, I investigated why, and it led me here.

  1. Is it possible to make the problem visible in a regression test (if so, please add a test)?

I don't think so, but maybe. The problem is that before this change, the DivRemPairs pass will generate non-deterministic use-list orderings. I could write a test that dumps the use-list info and check that, but that seems pretty fragile.

The answer to #1 suggests that we could reduce a codegen test based on whatever wiggled in test-suite? I don't know how much effort that requires, so if it doesn't seem worthwhile, I won't hold up this patch. I just want to know what I should do if I run into a similar problem. Also, @mgrang is the answer about the reverse-iteration-bot sufficient? (Again, I don't know anything about it, so trying to understand better.)

Apr 24 2018, 11:12 AM

Apr 23 2018

mgrang added a comment to D45858: [DivRemPairs] Fix non-determinism in use list order..

If there is a unit test for this then it should have been uncovered in the reverse iteration bot: http://lab.llvm.org:8011/builders/reverse-iteration

Apr 23 2018, 11:53 AM

Apr 22 2018

mgrang committed rC330561: [XRay] Change std::sort to llvm::sort in response to r327219.
[XRay] Change std::sort to llvm::sort in response to r327219
Apr 22 2018, 5:53 PM
mgrang committed rL330561: [XRay] Change std::sort to llvm::sort in response to r327219.
[XRay] Change std::sort to llvm::sort in response to r327219
Apr 22 2018, 5:52 PM

Apr 20 2018

mgrang added a comment to D39053: [Bitfield] Add more cases to making the bitfield a separate location.

Here is a test case which improves with this patch (for RISCV target). It is able to detect load/store halfword for size 16 bitfields.

Apr 20 2018, 12:17 PM

Apr 19 2018

mgrang created D45831: [docs] Add a note on non-deterministic sorting order of equal elements.
Apr 19 2018, 11:54 AM

Apr 18 2018

mgrang added a comment to D39053: [Bitfield] Add more cases to making the bitfield a separate location.

With this patch we get ~1800 bytes improvement on one of our internal codebases. I also ran spec2000/spec2006 validations (for RISCV) and there were no regressions. There were also no code size improvements seen in spec.

Apr 18 2018, 11:28 AM

Apr 17 2018

mgrang added a comment to D39053: [Bitfield] Add more cases to making the bitfield a separate location.

Added @apazos and myself a reviewers since this is something we would be interested in getting to work.

Apr 17 2018, 6:01 PM
mgrang added reviewers for D39053: [Bitfield] Add more cases to making the bitfield a separate location: apazos, mgrang.
Apr 17 2018, 6:00 PM

Apr 16 2018

mgrang committed rL330148: [RISCV] Fix assert message operator.
[RISCV] Fix assert message operator
Apr 16 2018, 11:59 AM
mgrang closed D45660: [RISCV] Fix assert message operator.
Apr 16 2018, 11:59 AM

Apr 14 2018

mgrang created D45660: [RISCV] Fix assert message operator.
Apr 14 2018, 8:53 PM

Apr 13 2018

mgrang abandoned D44363: [llvm] Change std::sort to llvm::sort in response to r327219.

All the smaller llvm patches are now merged. We can abandon this patch.

Apr 13 2018, 12:55 PM
mgrang committed rL330061: [DebugInfo] Change std::sort to llvm::sort in response to r327219.
[DebugInfo] Change std::sort to llvm::sort in response to r327219
Apr 13 2018, 12:54 PM
mgrang committed rL330059: [Transforms] Change std::sort to llvm::sort in response to r327219.
[Transforms] Change std::sort to llvm::sort in response to r327219
Apr 13 2018, 12:51 PM
mgrang closed D45142: [Transforms] Change std::sort to llvm::sort in response to r327219.
Apr 13 2018, 12:51 PM
mgrang committed rL330058: [MC] Change std::sort to llvm::sort in response to r327219.
[MC] Change std::sort to llvm::sort in response to r327219
Apr 13 2018, 12:50 PM
mgrang closed D45138: [MC] Change std::sort to llvm::sort in response to r327219.
Apr 13 2018, 12:50 PM
mgrang committed rL330057: [ProfileData] Change std::sort to llvm::sort in response to r327219.
[ProfileData] Change std::sort to llvm::sort in response to r327219
Apr 13 2018, 12:50 PM
mgrang closed D45139: [ProfileData] Change std::sort to llvm::sort in response to r327219.
Apr 13 2018, 12:49 PM
mgrang committed rL330053: [LTO] Change std::sort to llvm::sort in response to r327219.
[LTO] Change std::sort to llvm::sort in response to r327219
Apr 13 2018, 12:17 PM
mgrang closed D45137: [LTO] Change std::sort to llvm::sort in response to r327219.
Apr 13 2018, 12:17 PM

Apr 12 2018

mgrang committed rC329941: [RISCV] Fix logic to check if frame pointer should be used.
[RISCV] Fix logic to check if frame pointer should be used
Apr 12 2018, 12:36 PM
mgrang committed rL329941: [RISCV] Fix logic to check if frame pointer should be used.
[RISCV] Fix logic to check if frame pointer should be used
Apr 12 2018, 12:36 PM
mgrang closed D45237: [RISCV] Fix logic to check if frame pointer should be used.
Apr 12 2018, 12:36 PM

Apr 9 2018

mgrang added a comment to D45138: [MC] Change std::sort to llvm::sort in response to r327219.

I'm not familiar with r327219, but if a decision to use randomized sort has been made, why don't you replace all occurrences of std::sort with llvm::sort in a single patch? I don't think that an author of each file don't have to understand this kind of change and approve individually.

Apr 9 2018, 3:13 PM
mgrang committed rL329607: [WebAssembly] Change std::sort to llvm::sort in response to r327219.
[WebAssembly] Change std::sort to llvm::sort in response to r327219
Apr 9 2018, 12:41 PM
mgrang closed D44873: [WebAssembly] Change std::sort to llvm::sort in response to r327219.
Apr 9 2018, 12:41 PM
mgrang added a comment to D45140: [Support] Change std::sort to llvm::sort in response to r327219.

Exactly that's what I thought too, and llvm::sort already accepts a range (Container.begin(), Container.end()). In that case, could you please clarify what exactly do you mean by a "range-based variant" and its use cases in LLVM?

Ah, sorry! A "range-based" collection algorithm means one that takes a "range" as an argument instead of a pair of iterators. The "range" is anything that has begin and end iterators. ("Container-based algorithm" might have been a better name, since usually the "range" you pass is the entire container, but "range" is already an accepted term in C++ language and library discussions.)

So in this case, the call would look like this:

llvm::sort(TimersToPrint);

You can check out the implementation of llvm::none_of in include/llvm/ADT/STLExtras.h to see how this works. It just forwards on to the regular implementation.

None of this is related to your shuffling work, by the way; it's just odd and a bit inconsistent that there's an llvm:: algorithm that only takes iterators.

Apr 9 2018, 11:46 AM
mgrang added a comment to D45140: [Support] Change std::sort to llvm::sort in response to r327219.

Are there instances in llvm where we perform range-based sorting? I see that std has an experimental range-based sort (std::experimental::ranges::sort) which I don't see being used in llvm.

I think in practice almost *every* sort we do would be range-based (i.e. we almost always sort an entire container). We generally don't use std::experimental things in LLVM because they're not reliably present across platforms, but that doesn't mean we don't provide our own implementations for good ideas.

Also what should be the semantics of a range-based shuffle sort? Will it just shuffle the given range? Or should it shuffle the entire container but just sort the range?

I don't understand this question. You can't get to the entire container from a range.

Apr 9 2018, 11:31 AM
mgrang added a comment to D44873: [WebAssembly] Change std::sort to llvm::sort in response to r327219.

Ping for reviews please.

Apr 9 2018, 10:28 AM
mgrang added a comment to D45137: [LTO] Change std::sort to llvm::sort in response to r327219.

Ping for reviews please.

Apr 9 2018, 10:28 AM
mgrang added a comment to D45138: [MC] Change std::sort to llvm::sort in response to r327219.

Ping for reviews please.

Apr 9 2018, 10:28 AM
mgrang added a comment to D45139: [ProfileData] Change std::sort to llvm::sort in response to r327219.

Ping for reviews please.

Apr 9 2018, 10:28 AM
mgrang added a comment to D45142: [Transforms] Change std::sort to llvm::sort in response to r327219.

Ping for reviews please.

Apr 9 2018, 10:27 AM

Apr 8 2018

mgrang updated the diff for D45237: [RISCV] Fix logic to check if frame pointer should be used.

Added unit tests.

Apr 8 2018, 9:35 PM
mgrang committed rL329536: [Support] Change std::sort to llvm::sort in response to r327219.
[Support] Change std::sort to llvm::sort in response to r327219
Apr 8 2018, 9:50 AM
mgrang closed D45140: [Support] Change std::sort to llvm::sort in response to r327219.
Apr 8 2018, 9:50 AM
mgrang committed rL329535: [PowerPC] Change std::sort to llvm::sort in response to r327219.
[PowerPC] Change std::sort to llvm::sort in response to r327219
Apr 8 2018, 9:48 AM
mgrang closed D44870: [PowerPC] Change std::sort to llvm::sort in response to r327219.
Apr 8 2018, 9:48 AM
mgrang closed D44874: [X86] Change std::sort to llvm::sort in response to r327219.
Apr 8 2018, 9:46 AM
mgrang committed rL329534: [X86] Change std::sort to llvm::sort in response to r327219.
[X86] Change std::sort to llvm::sort in response to r327219
Apr 8 2018, 9:46 AM
mgrang added a comment to D44363: [llvm] Change std::sort to llvm::sort in response to r327219.

What is left to do in this patch?

Apr 8 2018, 9:32 AM