nemanjai (Nemanja Ivanovic)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 23 2015, 9:38 AM (160 w, 5 d)

Recent Activity

Yesterday

nemanjai committed rL325739: [PowerPC] Do not produce invalid CTR loop with an FRem.
[PowerPC] Do not produce invalid CTR loop with an FRem
Wed, Feb 21, 7:04 PM

Fri, Feb 16

nemanjai added a comment to D43235: [SchedModel] Complete models shouldn't match against itineraries when they don't use them (PR35639) (WIP).

I can confirm that the purpose of ItinRW is to avoid the need to define InstRW for a subtarget when the target already had itinerary classes. (Things would be *a lot* simpler if all the subtargets used the same style of machine description.)

CompleteModel can mean whatever is currently most useful to devs, but we don't want to lose the scheduling-time checks just because a subtarget doesn't define InstRW for everything. Maybe it would work for those subtargets should have InstRW { let Unsupported = 1 } for opcodes that aren't covered by itinerary classes?

Fri, Feb 16, 10:57 AM
nemanjai committed rL325347: [PowerPC] Fix transform in table gen file causing UB.
[PowerPC] Fix transform in table gen file causing UB
Fri, Feb 16, 6:51 AM

Thu, Feb 15

nemanjai updated the diff for D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Updated to use llvm::SmallSet instead of std::set.

Thu, Feb 15, 12:36 PM
nemanjai added inline comments to D43086: [PowerPC] Infrastructure work. Implement getting the opcode for a spill in one place..
Thu, Feb 15, 9:25 AM
nemanjai added a comment to D43315: [PowerPC] Optimize TLS initial-exec sequence to use X-Form loads/stores.

Please don't forget the diff context (that is missing with this patch).

Thu, Feb 15, 6:04 AM
nemanjai accepted D42602: [PowerPC] Reduce stack frame for fastcc functions by only allocating parameter save area when needed.

LGTM

Thu, Feb 15, 5:23 AM

Wed, Feb 14

nemanjai added a comment to D43235: [SchedModel] Complete models shouldn't match against itineraries when they don't use them (PR35639) (WIP).

I was under the impression that the purpose of ItinRW is a way to map processor resources to itineraries that were already defined. This in turn prevents the need to update existing instructions (since they have been defined with a list of itineraries).

Wed, Feb 14, 11:29 AM

Wed, Feb 7

nemanjai added inline comments to D42602: [PowerPC] Reduce stack frame for fastcc functions by only allocating parameter save area when needed.
Wed, Feb 7, 4:34 PM
nemanjai added inline comments to D40554: [PowerPC] Fix bugs in sign-/zero-extension elimination.
Wed, Feb 7, 12:39 PM
nemanjai abandoned D22194: Power9 - Add exploitation of oris/ori fusion.
Wed, Feb 7, 12:24 PM
nemanjai commandeered D22194: Power9 - Add exploitation of oris/ori fusion.

Taking this over to abandon the revision as there are currently no plans to implement instruction fusion for Power9.

Wed, Feb 7, 12:24 PM
nemanjai added a comment to D38778: Implement rudimentary support for the PowerPC SPE APU.
  • Considering we have a mutually exclusive situation between FPU and SPE and the sheer prevalence of FPU cores and developers adding code for those, it would probably be a good idea to add some checks that we don't break SPE. What I'm thinking would be a good idea is a linear traversal in SDAG post-processing that would ensure that all the MachineSDNodes in the DAG are available on SPE. I think this can simply be done by checking the operand/result register classes to make sure you don't end up with any F4RC or F8RC registers. Of course, this check would only fire on SPE subtargets.

Of course, this won't catch late additions such as regclass copies and MachineInstr's we add in various MI-level passes and late pseudo-expansion, so perhaps the better choice would be to catch this in EmitInstruction by getting the MCInstrDesc for the MI and checking the register class there.

Wed, Feb 7, 6:57 AM
nemanjai added a comment to D38778: Implement rudimentary support for the PowerPC SPE APU.

I have gotten to PPCInstrInfo.td and wanted to submit the comments rather than delaying the review further until I am completely done with it. I'll continue to review it and add comments over the remainder of the week.
A couple of general notes:

  • In retrospect, the review process would have probably been much quicker and easier if this was split up into a bunch of smaller patches. Perhaps the target features and calling convention in the first, then the new register classes and spill/restore bits, then legalization of small groups of instructions along with the associated intrinsics/builtins/tests, etc.
  • Considering we have a mutually exclusive situation between FPU and SPE and the sheer prevalence of FPU cores and developers adding code for those, it would probably be a good idea to add some checks that we don't break SPE. What I'm thinking would be a good idea is a linear traversal in SDAG post-processing that would ensure that all the MachineSDNodes in the DAG are available on SPE. I think this can simply be done by checking the operand/result register classes to make sure you don't end up with any F4RC or F8RC registers. Of course, this check would only fire on SPE subtargets.
  • Is there a Clang portion to follow? To define builtins for all the intrinsics in C/C++. Or do you not plan to target SPE from C/C++?
Wed, Feb 7, 5:24 AM

Tue, Feb 6

nemanjai added a comment to D42109: [PowerPC] Follow-up to r322373 for materializing constants that set the CR.

Ping. Does anyone on the reviewer list have some time to review this?

Tue, Feb 6, 4:25 AM
nemanjai abandoned D27366: [PowerPC][WIP] Provide context-sensitive cost to the Greedy Allocator to favour splitting over CSR first use.

We decided not to pursue this further as there are better approaches to aiding shrink wrapping.

Tue, Feb 6, 4:23 AM

Mon, Feb 5

nemanjai added a comment to D42793: [MergeICmps] Enable the MergeICmps Pass by default..

Just wanted to also mention that this passes a double bootstrap build/lit/lnt on PPC.

Mon, Feb 5, 2:22 PM
nemanjai accepted D42793: [MergeICmps] Enable the MergeICmps Pass by default..

The PPC code looks way nicer. The alignment is fine as well - unaligned scalar loads are cheap on modern PPC HW and the loads are in bounds. Of course, I have no comment on the X86 code as I don't know enough about the target.
LGTM.

Mon, Feb 5, 12:11 PM
nemanjai accepted D39860: [PowerPC] Simplify a Swap if it feeds a Splat.

Thank you for fixing the issue with the register class - it has clearly existed in this code before your patch as well. My comments are minor nits.

Mon, Feb 5, 11:49 AM
nemanjai added a comment to D39942: [PPC] Add additional fnmadd patterns..

There is still no test case for XSNMADDADP. Also, since you're introducing pairs of patterns that generate each instruction, can you add a test case for each of the patterns.

Mon, Feb 5, 10:19 AM
nemanjai added inline comments to D40554: [PowerPC] Fix bugs in sign-/zero-extension elimination.
Mon, Feb 5, 9:58 AM

Fri, Feb 2

nemanjai added inline comments to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.
Fri, Feb 2, 6:11 AM
nemanjai resigned from D38128: Handle COPYs of physregs better (regalloc hints).

Thank you Jonas. As this no longer needs PPC input, I'm resigning from the review.

Fri, Feb 2, 6:06 AM
nemanjai abandoned D22193: Add macro-fusion hook in MIScheduler and support cluster instructions scheduling in PostRAScheduler.

There are no current plans to implement fusion. Abandoning this patch.

Fri, Feb 2, 6:03 AM
nemanjai commandeered D22193: Add macro-fusion hook in MIScheduler and support cluster instructions scheduling in PostRAScheduler.
Fri, Feb 2, 6:01 AM
nemanjai added a comment to D37991: [PowerPC] Turn on branch coalescing by default for power.

Have we forgotten about this? Can we decide to either abandon, update or proceed with this patch?

Fri, Feb 2, 6:00 AM
nemanjai added a comment to D39536: [PowerPC] Eliminate redundant register copys after register allocation.

Now that https://reviews.llvm.org/rL323991 has actually landed, can you re-evaluate whether this patch is still applicable and if so, whether it needs any changes. Also, have you looked into Hal's suggestion?

Fri, Feb 2, 5:59 AM
nemanjai added a comment to D40298: [PowerPC] Merge register copies.

Can you please re-evaluate the applicability and functionality of this patch in light of related patches that recently landed. For example, does https://reviews.llvm.org/rL323991 affect this patch?

Fri, Feb 2, 5:55 AM
nemanjai added inline comments to D42590: [PowerPC] Try to move the stack pointer update instruction later in the prologue and earlier in the epilogue (Version 2).
Fri, Feb 2, 5:51 AM

Thu, Feb 1

nemanjai added inline comments to D42590: [PowerPC] Try to move the stack pointer update instruction later in the prologue and earlier in the epilogue (Version 2).
Thu, Feb 1, 3:47 PM
nemanjai accepted D42637: [PowerPC] Check hot loop exit edge in PPCCTRLoops.

LGTM.

Thu, Feb 1, 1:33 PM
nemanjai committed rL324005: [PowerPC] Tell VSX swap removal that scalar conversions are lane-sensitive.
[PowerPC] Tell VSX swap removal that scalar conversions are lane-sensitive
Thu, Feb 1, 1:10 PM

Wed, Jan 31

nemanjai added a comment to D42637: [PowerPC] Check hot loop exit edge in PPCCTRLoops.

This seems like a good thing to do. Would you be able to provide some benchmark data to show the impact?

Wed, Jan 31, 6:29 AM
nemanjai added inline comments to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.
Wed, Jan 31, 6:09 AM
nemanjai updated the diff for D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Benchmarking has shown that we should be concerned with any type of call in the case statements equally (i.e. indirect calls are no worse than direct). Furthermore, large switch statements can be lowered to jump tables without much penalty even if there are calls.

Wed, Jan 31, 6:06 AM

Mon, Jan 29

nemanjai accepted D38128: Handle COPYs of physregs better (regalloc hints).

This also reduces the overall number of register moves slightly. LGTM

Mon, Jan 29, 10:37 AM

Fri, Jan 26

nemanjai added a comment to D38128: Handle COPYs of physregs better (regalloc hints).

Ping!

Could anyone on PowerPC confirm these test changes and perhaps also that number of COPYs are decreasing overall, please.

Fri, Jan 26, 6:41 AM
nemanjai added a comment to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Could you go through the review comments and make sure you've addressed them?

Fri, Jan 26, 2:45 AM

Thu, Jan 25

nemanjai requested changes to D42101: [PowerPC] Legalize SETULT and SETUGT for type f32 and f64..
Thu, Jan 25, 2:10 PM

Jan 21 2018

nemanjai added a comment to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

I've finally gotten around to benchmarking this. I'll try to attach the full summary (warning: it is a large PDF file) and here is a somewhat concise summary of what I've done to benchmark this:

Jan 21 2018, 9:06 PM

Jan 16 2018

nemanjai created D42109: [PowerPC] Follow-up to r322373 for materializing constants that set the CR.
Jan 16 2018, 9:42 AM

Jan 12 2018

nemanjai committed rL322372: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.
[PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP
Jan 12 2018, 7:02 AM
nemanjai closed D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.
Jan 12 2018, 7:02 AM

Jan 11 2018

nemanjai added a comment to D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization..

The PPC-specific part I discussed with Uli is in D41856.

Jan 11 2018, 2:07 PM

Jan 10 2018

nemanjai updated the diff for D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.

Legalize by producing PPC-specific atomic compare and swap ISD nodes.

Jan 10 2018, 4:29 PM
nemanjai added inline comments to D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.
Jan 10 2018, 1:09 PM
nemanjai added a comment to D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.

Do you mean that the general approach of updating the nodes during custom legalization is fragile

Yes. The problem is that you're essentially attaching additional semantics to a target-independent opcode (specifically, that the "unused" bits of the ATOMIC_CMP_SWAP must be zero). DAGCombine doesn't understand this, and can therefore break your assumptions. This has come up before in other contexts (e.g. D31331).

The clean approach is to introduce a target-specific node (e.g. PPCISD::ATOMIC_CMP_SWAP), and custom-lower ISD::ATOMIC_CMP_SWAP to PPCISD::ATOMIC_CMP_SWAP; that way, it's clear your node has different semantics.

Jan 10 2018, 12:11 PM
nemanjai updated the diff for D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.

Updated to use MaskedValueIsZero() instead of a custom function. Thanks for the suggestion Eli.

Jan 10 2018, 9:01 AM
nemanjai added a comment to D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.

With this approach, I'm a little worried it will break in the future. For stores, DAGCombine calls SimplifyDemandedBits to simplify the input; if someone added the same functionality for atomic operations, it would break this check.

Jan 10 2018, 6:53 AM
nemanjai added a reviewer for D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP: efriedma.
Jan 10 2018, 6:27 AM

Jan 9 2018

nemanjai added a comment to D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.

My plan is to write a test case in projects/test-suite that will test these sub-word atomic compare-and-swap operations with negative values in various contexts (compare input is constant, parameter, loaded value, computed value). If there are no objections to this of course.

Jan 9 2018, 2:33 AM
nemanjai created D41856: [PowerPC] Zero-extend the compare operand for ATOMIC_CMP_SWAP.
Jan 9 2018, 2:27 AM

Jan 8 2018

nemanjai abandoned D41791: [DAG Legalization] Zero-extend the value compared in cmpxchg.

Abandoning this as at least one target prefers that the compare input be any-extended and each target decide what to do about the high bits that may differ between the two values.

Jan 8 2018, 10:00 AM
nemanjai added a comment to D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization..

But that's not what the TLI hook says as I understand it; the TLI hook simply allows the back-end to inform common code how the result of a sub-word ATOMIC_CMP_SWAP will have been extended (either by hardware or by the back-end specific implementation). It doesn't say anything about inputs.

I have a similar understanding of the hook - i.e. how the results of atomic operations are extended. I guess I just see ATOMIC_CMP_SWAP as one where the input should conform to this as well as it is really a load-compare-store operation, so its input will be compared to a value that is loaded atomically. Namely, it's input should have the same high bits as the result of ATOMIC_LOAD.

And it's not clear that inputs really need to be extended in any particular way anyway -- if the back-end has sub-word instructions, those will likely ignore high bits anyway; and if the back-end creates a compare-and-swap loop on the surrounding word, it may be able (like SystemZ) to implement the necessary comparisons without explicit extensions. So IMO this is best left to each target.

If a target has sub-word instructions for all three operations, I suppose it doesn't care if the loaded value and the comparand have different high bits. In all other cases, the target ultimately has to do the work of ensuring the high bits are set the same way for both values at some point. It seemed to me that legalization would be a logical place for ensuring that work is done, but of course since there are objections, I'll just fix that in the PPC target.

Jan 8 2018, 9:55 AM
nemanjai added a comment to D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization..

Sure, the operands will have been any-extended from i8/i16 to i32. But the target knows that this happened, because it knows that this is a i8/i16 ATOMIC_CMP_SWAP (via getMemoryVT). In that case, if it actually requires a particular sign- or zero-extended version of the original i8/i16 constant, it can still do the appropriate in-reg extension from the any-extended i32 value it got.

Oh OK, of course. I mentioned in the original patch that I can certainly fix this in the PPC back end. I imagine that other back ends have done the same thing one way or another (or have a bug in this they don't know about just as PPC does). However, I ultimately don't see the utility in type-legalization ignoring how the target wants these inputs extended and doing an any-extend when the target is going to have to pick one down the line. And the target has already stated how it wants atomics extended in that TLI hook.

Jan 8 2018, 9:01 AM
nemanjai added a comment to D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization..

This patch seems to be identical to the one I proposed here:
https://reviews.llvm.org/D38215

(While as mentioned there, this is no longer needed on SystemZ, I still think this is a correct change.)

As to Nemanja's comments, in the default expansion of ATOMIC_CMP_SWAP_WITH_SUCCESS, the result of an ATOMIC_CMP_SWAP call is compared with the compare value. Since the result of ATOMIC_CMP_SWAP may be differently extended depending on the platform (this is what TLI.getExtendForAtomicOps is all about), the compare value must be extended in the same way. E.g. on Mips, where TLI.getExtendForAtomicOps is SIGN_EXTEND, the compare value must likewise be always sign-extended, or else the comparison will fail.

Given that which extension is correct depends on the platform, it doesn't seem to make much sense to me to do an unconditional zero-extension of the compare value in common code ahead of time.

Fair enough. I agree.

Jan 8 2018, 8:33 AM

Jan 7 2018

nemanjai added a comment to D41791: [DAG Legalization] Zero-extend the value compared in cmpxchg.

(It looks like https://reviews.llvm.org/D41798 fixes your testcase?)

Jan 7 2018, 7:24 AM
nemanjai added a comment to D41798: [LegalizeDAG] Fix ATOMIC_CMP_SWAP_WITH_SUCCESS legalization..

I should start by saying that I think this patch seems to me rather uncontroversial, but I don't think it is adequate to address the original problem (explanation follows).

Jan 7 2018, 7:16 AM

Jan 5 2018

nemanjai added a comment to D41737: [PowerPC] Try to move the stack pointer update instruction later in the prologue and earlier in the epilogue.

These comments are not an indication that another review is necessary, but please address them on the commit.

Jan 5 2018, 4:21 PM
nemanjai created D41791: [DAG Legalization] Zero-extend the value compared in cmpxchg.
Jan 5 2018, 3:49 PM
nemanjai accepted D41758: [PowerPC] Fix assertion due to assuming a type is simple..

OK, I don't think there's an issue with this - if the vector just happens to be wider, we'll end up needing more of the respective instructions, but it won't turn anything into a library call that wouldn't be a library call otherwise.
LGTM.

Jan 5 2018, 2:12 PM

Jan 3 2018

nemanjai added a comment to D41665: [Docs] Add Contributing page..

I think this is a great start. Thanks Florian.

Jan 3 2018, 8:34 AM

Jan 2 2018

nemanjai added a comment to D41665: [Docs] Add Contributing page..

I think it's really cool that you've started on this and I think this is a great start. Thanks.

Jan 2 2018, 7:22 AM

Dec 29 2017

nemanjai accepted D40893: [PowerPC] fix a bug in TCO eligibility check.

LGTM

Dec 29 2017, 8:00 AM
nemanjai committed rL321551: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.
[PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion
Dec 29 2017, 4:23 AM
nemanjai closed D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.
Dec 29 2017, 4:23 AM

Dec 28 2017

nemanjai updated the diff for D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.

Add a test case for the edge case where operand 3 of RLWINM is a zero.

Dec 28 2017, 4:09 AM

Dec 27 2017

nemanjai updated the diff for D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.

Fix the UB identified by Ben Kramer - thanks Ben.

Dec 27 2017, 10:38 PM

Dec 20 2017

nemanjai added a comment to rL321089: [DAG] Elide overlapping store.

This has broken all the PowerPC buildbots. I'll pull this patch to get the bots back to green unless you have a fix available. The smallest failing benchmark from the test-suite is sieve.c.
This patch removes half of the pre-inc stores that are actually needed. I imagine that the DAGCombiner is getting rid of these stores before they become pre-inc stores since there's a check for unindexed stores as part of this patch, but I haven't spent the time to really understand what this patch does.
I'm attaching both the IR generated for sieve.c as well as a bugpoint-reduced version of it (the reduction was done by comparing the number of pre-inc stores emitted before the patch and after it).

Dec 20 2017, 9:35 AM
nemanjai committed rL321182: [JumpTables] Let targets decide which switch instructions are suitable.
[JumpTables] Let targets decide which switch instructions are suitable
Dec 20 2017, 7:45 AM
nemanjai added a comment to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Given that the plan to make the functions in TargetLowering virtual is generally accepted, could you commit that part? This would solve a problem we're facing in some downstream code.

Dec 20 2017, 6:45 AM

Dec 19 2017

nemanjai added inline comments to D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.
Dec 19 2017, 8:55 AM

Dec 18 2017

nemanjai updated the diff for D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.

The update_llc_checks.py script seems to have produced a CHECK directive that doesn't actually pass. Fixed the test case.

Dec 18 2017, 3:47 PM
nemanjai created D41369: [PowerPC] Fix for PR35688 - handle out-of-range values for r+r to r+i conversion.
Dec 18 2017, 3:12 PM

Dec 15 2017

nemanjai committed rL320811: Fix the second build bot break introduced by r320791..
Fix the second build bot break introduced by r320791.
Dec 15 2017, 6:18 AM
nemanjai committed rL320806: Fix code causing fallthrough warnings in the PPC back end..
Fix code causing fallthrough warnings in the PPC back end.
Dec 15 2017, 3:48 AM
nemanjai committed rL320798: Fix the build bot break introduced by r320791..
Fix the build bot break introduced by r320791.
Dec 15 2017, 1:52 AM

Dec 14 2017

nemanjai closed D31852: [PowerPC] Convert reg/reg instructions fed by constants to reg/imm instructions (pre and post RA).

Committed in https://reviews.llvm.org/rL320791

Dec 14 2017, 11:32 PM
nemanjai committed rL320791: [PowerPC] Convert r+r instructions to r+i (pre and post RA).
[PowerPC] Convert r+r instructions to r+i (pre and post RA)
Dec 14 2017, 11:28 PM
nemanjai added a comment to rL320614: AMDGPU: Partially fix disassembly of MIMG instructions.

This causes failures on our build bot. Unfortunately, there was a different failure introduced by a previous commit that hid this. The failures are here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5020.

Since this is a bootstrap failure, I imagine this patch isn't necessarily the culprit but it may be bringing out a latent bug. I am investigating it right now, but in the interest of bringing the build bot back to green, would you be able to revert this until I know what the problem is?

Dec 14 2017, 5:42 PM
nemanjai committed rL320786: Disabling r312514 as it causes miscompiles that show up on bootstrap.
Disabling r312514 as it causes miscompiles that show up on bootstrap
Dec 14 2017, 5:38 PM
nemanjai added a comment to rL320614: AMDGPU: Partially fix disassembly of MIMG instructions.

This causes failures on our build bot. Unfortunately, there was a different failure introduced by a previous commit that hid this. The failures are here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/5020.

Dec 14 2017, 7:50 AM

Dec 13 2017

nemanjai added a comment to rCTE320486: [clangd] Introduce a "Symbol" class..

I've already posted this comment on https://reviews.llvm.org/rL320486:

Dec 13 2017, 11:15 PM
nemanjai added a comment to rL320486: [clangd] Introduce a "Symbol" class..

This commit seems to have broken our build bot. Can you please investigate and fix it. The failure:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-multistage/builds/4980/steps/ninja%20check%202/logs/stdio

Dec 13 2017, 9:20 AM
nemanjai committed rL320589: Fix link failure on one build bot introduced by r320584..
Fix link failure on one build bot introduced by r320584.
Dec 13 2017, 7:28 AM
nemanjai added inline comments to D31852: [PowerPC] Convert reg/reg instructions fed by constants to reg/imm instructions (pre and post RA).
Dec 13 2017, 6:51 AM
nemanjai committed rL320584: [PowerPC] MachineSSA pass to reduce the number of CR-logical operations.
[PowerPC] MachineSSA pass to reduce the number of CR-logical operations
Dec 13 2017, 6:48 AM
nemanjai closed D30431: [PowerPC] MachineSSA pass to reduce the number of CR-logical operations.
Dec 13 2017, 6:48 AM
nemanjai added inline comments to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.
Dec 13 2017, 2:31 AM

Dec 12 2017

nemanjai closed D39924: [PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels.

Committed in r318044.

Dec 12 2017, 9:04 AM
nemanjai committed rL320475: [PowerPC] Add branch flag on asm parser-only branch instructions.
[PowerPC] Add branch flag on asm parser-only branch instructions
Dec 12 2017, 4:33 AM
nemanjai closed D40846: Add branch flag on branch instructions.
Dec 12 2017, 4:33 AM
nemanjai committed rL320473: [PowerPC] Follow-up to r318436 to get the missed CSE opportunities.
[PowerPC] Follow-up to r318436 to get the missed CSE opportunities
Dec 12 2017, 4:10 AM
nemanjai closed D40348: [PowerPC] Follow-up to r318436 to get the missed CSE opportunities.
Dec 12 2017, 4:10 AM

Dec 11 2017

nemanjai added a comment to D40846: Add branch flag on branch instructions.

@nemanjai, I still don't have permissions for committing, so could you commit this?
Thanks!

Dec 11 2017, 11:17 AM
nemanjai committed rL320368: [PowerPC] Sign-extend negative constant stores.
[PowerPC] Sign-extend negative constant stores
Dec 11 2017, 6:36 AM
nemanjai committed rL320365: [DAGCombiner] Add combined indexed load to the work list.
[DAGCombiner] Add combined indexed load to the work list
Dec 11 2017, 6:16 AM

Dec 9 2017

nemanjai updated the diff for D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Address comments from Eli. Thanks Eli!

Dec 9 2017, 1:29 AM

Dec 8 2017

nemanjai added a reviewer for D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables: efriedma.
Dec 8 2017, 11:38 PM
nemanjai added a comment to D41029: [JumpTables][PowerPC] Let targets decide which switch instructions are suitable for jump tables.

Eli, thanks so much for your comments. Please keep them coming. I'm not trying to be difficult about any of this - I just want to make sure the final implementation does the right thing both for compile time and run time.
I probably should have noted in the description that this provides significant run time improvements on some important workloads.

Dec 8 2017, 2:55 PM