Page MenuHomePhabricator

kbarton (Kit Barton)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 13 2015, 12:58 PM (223 w, 1 d)

Recent Activity

Today

kbarton committed rG8e64f0a64988: Fix unused variable warning in LoopFusion pass. (authored by kbarton).
Fix unused variable warning in LoopFusion pass.
Wed, Apr 24, 7:09 PM
kbarton committed rL359161: Fix unused variable warning in LoopFusion pass..
Fix unused variable warning in LoopFusion pass.
Wed, Apr 24, 7:08 PM
kbarton closed D61035: Fix unused variable warning in LoopFusion pass.
Wed, Apr 24, 7:08 PM · Restricted Project

Yesterday

kbarton created D61035: Fix unused variable warning in LoopFusion pass.
Tue, Apr 23, 12:27 PM · Restricted Project

Wed, Apr 17

kbarton committed rG3cdf87940f05: Add basic loop fusion pass. (authored by kbarton).
Add basic loop fusion pass.
Wed, Apr 17, 11:52 AM
kbarton committed rL358607: Add basic loop fusion pass..
Add basic loop fusion pass.
Wed, Apr 17, 11:51 AM
kbarton closed D55851: Implement basic loop fusion pass.
Wed, Apr 17, 11:51 AM · Restricted Project

Tue, Apr 16

kbarton committed rGab70da07286e: Add basic loop fusion pass. (authored by kbarton).
Add basic loop fusion pass.
Tue, Apr 16, 6:36 PM
kbarton committed rL358543: Add basic loop fusion pass..
Add basic loop fusion pass.
Tue, Apr 16, 6:35 PM
kbarton added a comment to D55851: Implement basic loop fusion pass.

All comments have been addressed. I will be committing this soon.

Tue, Apr 16, 10:41 AM · Restricted Project

Thu, Apr 11

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

Is this patch dead? Does @kbarton or perhaps @jonpa have any interest in seeing this through so IPRA can be enabled on PPC/SystemZ?

Thu, Apr 11, 9:43 AM · Restricted Project
kbarton closed D50988: Remove Darwin support from POWER backend..

This landed in https://reviews.llvm.org/rL340795.

Thu, Apr 11, 9:41 AM · Restricted Project

Tue, Mar 26

kbarton added a comment to D55851: Implement basic loop fusion pass.

Thanks @dmgreen!
The only outstanding issue was from @Meinersbur regarding the constructor for FusionCandidate. The concern was keeping the logic in the constructor, vs moving it out into a createFusionCandidate method to wrap the constructor and add all the logic to that method. I don't have a preference one way or the other, but will happily make the change if people feel strongly about it.

Tue, Mar 26, 9:14 AM · Restricted Project

Mon, Mar 25

kbarton updated the diff for D55851: Implement basic loop fusion pass.

Address review comments as follows:

  1. Strengthen dependence checks between any value used in Loop 1 to ensure it is not defined in loop 0.
  2. Do not add a tree update to insert an edge between FC0.Latch and FC1.Header when FC0.ExitingBlock is the same as FC0.Latch. This edge has already been inserted into the tree updates earlier and will cause an assertion to fail while performing the updates.
  3. Rename ExitingBlocks to ExitingBlock since we are only concerned with loops with a single exiting block.
Mon, Mar 25, 8:24 PM · Restricted Project
kbarton added inline comments to D55851: Implement basic loop fusion pass.
Mon, Mar 25, 8:18 PM · Restricted Project

Mar 22 2019

kbarton added inline comments to D55851: Implement basic loop fusion pass.
Mar 22 2019, 2:08 PM · Restricted Project

Mar 1 2019

kbarton updated the diff for D55851: Implement basic loop fusion pass.

Addressed most of the review comments.

Mar 1 2019, 10:02 AM · Restricted Project
kbarton added a comment to D55851: Implement basic loop fusion pass.

Addressed some more comments. I'll upload a new patch momentarily.

Mar 1 2019, 9:03 AM · Restricted Project

Feb 12 2019

kbarton added a comment to D55851: Implement basic loop fusion pass.

I've addressed almost all of the comments.
I will work on an update to the problem that dmgreen provided an example for and post a new version of the patch when that is done.
In the meantime, if my understanding of the comments is incorrect, someone please correct me :)

Feb 12 2019, 9:59 AM · Restricted Project

Jan 18 2019

kbarton added a comment to D56906: Prototype of update to file headers for relicensing..

You probably realize this, but the link https://llvm.org/LICENSE.txt currently doesn't work ;)
Are you planning on including a copy of the LICENSE.txt file in the source tree as well?

Jan 18 2019, 8:52 AM

Jan 17 2019

kbarton updated the diff for D55851: Implement basic loop fusion pass.

Addressed comments from dmgreen.

Jan 17 2019, 1:59 PM · Restricted Project
kbarton added a comment to D55851: Implement basic loop fusion pass.

I've addressed most of these comments (except the ones I have some questions about). I will be refreshing the patch momentarily.

Jan 17 2019, 1:58 PM · Restricted Project

Dec 20 2018

kbarton added inline comments to D55851: Implement basic loop fusion pass.
Dec 20 2018, 12:51 PM · Restricted Project
kbarton updated the diff for D55851: Implement basic loop fusion pass.

Addressed all but two of the review comments.
The only outstanding comments are the use of std::set (which I tried to address with comments) and the logic inside the FusionCandidate constructor (which I'm waiting for feedback on the review).

Dec 20 2018, 12:41 PM · Restricted Project
kbarton updated the summary of D55851: Implement basic loop fusion pass.
Dec 20 2018, 9:28 AM · Restricted Project
kbarton added a comment to D55851: Implement basic loop fusion pass.

Responded to two of the comments. Most of the others will be addressed in the next revision, which I should hopefully be uploading soon.

Dec 20 2018, 9:26 AM · Restricted Project

Dec 18 2018

kbarton created D55851: Implement basic loop fusion pass.
Dec 18 2018, 12:52 PM · Restricted Project

Aug 27 2018

kbarton committed rL340795: [PPC] Remove Darwin support from POWER backend..
[PPC] Remove Darwin support from POWER backend.
Aug 27 2018, 6:19 PM
kbarton committed rC340770: [PPC] Remove Darwin support from POWER backend..
[PPC] Remove Darwin support from POWER backend.
Aug 27 2018, 12:55 PM
kbarton committed rL340770: [PPC] Remove Darwin support from POWER backend..
[PPC] Remove Darwin support from POWER backend.
Aug 27 2018, 12:55 PM

Aug 20 2018

kbarton added a comment to D50988: Remove Darwin support from POWER backend..

Actually can you explain the removal of llvm/test/tools/dsymutil/PowerPC/sibling.test?

Aug 20 2018, 12:50 PM · Restricted Project
kbarton added a comment to D50988: Remove Darwin support from POWER backend..

I personally can't think of a reason why not to do this. But I think sending an RFC to llvm-dev is in order here.

Aug 20 2018, 12:44 PM · Restricted Project
kbarton added a parent revision for D50989: Remove Darwin support from POWER backend.: D50988: Remove Darwin support from POWER backend..
Aug 20 2018, 12:26 PM
kbarton added a child revision for D50988: Remove Darwin support from POWER backend.: D50989: Remove Darwin support from POWER backend..
Aug 20 2018, 12:26 PM · Restricted Project
kbarton created D50989: Remove Darwin support from POWER backend..
Aug 20 2018, 12:25 PM
kbarton created D50988: Remove Darwin support from POWER backend..
Aug 20 2018, 12:20 PM · Restricted Project
kbarton added a reviewer for D50965: [PowerPC] Fix label address calculation for ppc64: sfertile.

I'm not overly familiar with this. I think @sfertile is more familiar with this, so I've added him as a reviewer.

Aug 20 2018, 10:40 AM

Jul 24 2018

kbarton updated the diff for D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

Created a new function (isSafeForIPRA) to consistently check whether IPRA can be performed. This check is used in RegUsageInfoCollector as well as isSafeForNoCSROpt. I also went back to the original checks in isSafeForNoCSROpt to check for LocalLinkage.

Jul 24 2018, 2:52 AM · Restricted Project

Jul 17 2018

kbarton added inline comments to D45308: [IPRA] Do not collect register usage information on functions that can be derefined.
Jul 17 2018, 10:42 AM · Restricted Project

Jul 5 2018

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

Thanks @vivekvpandya for getting back to me.
I'll work on updating the patch now. I think we're on the same page with the potential problems.
Essentially, there seems to be some assumptions that when EnableIIPRA is set, it will work properly and add additional information that can be used. Now, with the early exit due to isDefinitionExact, that is not necessarily the case. So, I'm trying to put a check in to validate that IPRA was successful before using the information. This way, if we extend the checks in IPRA in the future, we don't need to continually replicate them in other places that rely on IPRA being successful.

Jul 5 2018, 8:23 AM · Restricted Project

Jun 27 2018

kbarton 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?

Jun 27 2018, 1:01 PM · Restricted Project

Jun 25 2018

kbarton accepted D48550: [PowerPC] Fix incorrectly encoded wait instruction.

LGTM.

Jun 25 2018, 11:59 AM

Jun 6 2018

kbarton updated the diff for D45308: [IPRA] Do not collect register usage information on functions that can be derefined.

Added the isDefinitionExact check to isSafeForNoCSROpt method.
Updated the test case to use -print-regusage to check for exact register clobbers computed by IPRA.

Jun 6 2018, 7:16 PM · Restricted Project
kbarton 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.

Jun 6 2018, 7:06 PM · Restricted Project

Apr 4 2018

kbarton created D45308: [IPRA] Do not collect register usage information on functions that can be derefined.
Apr 4 2018, 7:51 PM · Restricted Project

Oct 24 2017

kbarton accepted D34160: [Power9] Exploit vinserth instruction.

LGTM

Oct 24 2017, 3:27 PM
kbarton added inline comments to D39173: [MachineCSE] Add new callback for is caller preserved or constant physregs..
Oct 24 2017, 6:52 AM

Oct 23 2017

kbarton accepted D34630: [Power9] Add additional patterns to recognize and transform insertelt/extractelt to vinsert[h|b]/vextractu[h|b] instructions..

LGTM

Oct 23 2017, 8:07 PM
kbarton added inline comments to D34160: [Power9] Exploit vinserth instruction.
Oct 23 2017, 8:03 PM
kbarton added inline comments to D39173: [MachineCSE] Add new callback for is caller preserved or constant physregs..
Oct 23 2017, 6:46 AM

Aug 22 2017

kbarton accepted D34757: [PowerPC] better instruction selection for OR (XOR) with a 32-bit immediate.

LGTM

Aug 22 2017, 1:43 PM
kbarton accepted D33574: PPC: Verify that branch fixups fit within the range..

LGTM

Aug 22 2017, 1:40 PM
kbarton requested changes to D34630: [Power9] Add additional patterns to recognize and transform insertelt/extractelt to vinsert[h|b]/vextractu[h|b] instructions..

Did @nemanjai comment about the vector extracts get addressed?

Aug 22 2017, 1:36 PM
kbarton accepted D32776: [PowerPC] Update branch coalescing to be a PowerPC specific pass.

I would change the summary of this review to reflect the fact we are moving this pass back to the PPC target.
Aside from that, this LGTM.

Aug 22 2017, 1:26 PM
kbarton accepted D34497: [Power9] Exploit vinsertb instruction.

Aside from some minor changes to the comments, this LGTM.

Aug 22 2017, 1:20 PM
kbarton committed rL311486: [Docs] Update release notes for PPC.
[Docs] Update release notes for PPC
Aug 22 2017, 12:57 PM

Jul 10 2017

kbarton accepted D34337: [PPC] Fix two bugs in frame lowering..

LGTM. Just some minor updates in the comments.

Jul 10 2017, 9:15 AM

Jun 13 2017

kbarton committed rL305309: Test commit - NFC..
Test commit - NFC.
Jun 13 2017, 10:36 AM

Jun 12 2017

kbarton accepted D34092: [PPC] Enhance altivec conversion function macros implementation..

LGTM

Jun 12 2017, 12:53 PM
kbarton accepted D33690: [PowerPC] Match vec_revb builtins to P9 instructions..

LGTM

Jun 12 2017, 11:04 AM

Jun 5 2017

kbarton added a comment to D32536: Extend memcpy expansion in Transform/Utils to handle wider operand types..

I'm OK with this patch and then a follow-up patch to enable the new behaviour by default.
@arsenm Are you OK with this approach or do you prefer a different approach?

Jun 5 2017, 11:30 AM
kbarton added a comment to D32998: [SROA] enable splitting for non-whole-alloca loads and stores.

This looks OK to me, but I don't have enough knowledge of SROA to accept this.

Jun 5 2017, 11:17 AM
kbarton requested changes to D33715: [PPC] exploit rotate-left-then-mask-insert instructions for bitfield insert.

If I understand this correctly, you're trying to use the tryBitfieldInsert before the tryBitPermutation function because you can get cleaner code out of some cases of tryBitfieldInsert. However, you only want to use the tryBitfieldInsert on some cases, not on all. Is this correct?
If so, I think it makes sense to refactor the tryBitfieldInsert to focus on the specific cases you want to try and identify and then call the existing tryBitPermutation and the remaining tryBitfieldInsert afterwards. There may be some code duplication as a result (hopefully that can be minimal) but the logic will be easier to understand.

Jun 5 2017, 11:12 AM
kbarton added inline comments to D33690: [PowerPC] Match vec_revb builtins to P9 instructions..
Jun 5 2017, 10:54 AM
kbarton accepted D33519: [PPC] Lower llvm.ppc.cfence(constant) to no-op..

LGTM.

Jun 5 2017, 10:39 AM
kbarton added inline comments to D33574: PPC: Verify that branch fixups fit within the range..
Jun 5 2017, 10:35 AM

May 25 2017

kbarton accepted D33482: [PPC] Fix assertion failure during binary encoding with -mcpu=pwr9 .

Aside from a spelling mistake, LGTM.

May 25 2017, 3:35 PM
kbarton accepted D33510: [Power9] Exploit vector integer extend instructions.

LGTM

May 25 2017, 3:04 PM
kbarton added inline comments to D33519: [PPC] Lower llvm.ppc.cfence(constant) to no-op..
May 25 2017, 2:51 PM
kbarton added inline comments to D33404: [PowerPC] Fix a performance bug for PPC::XXPERMDI..
May 25 2017, 11:23 AM

May 16 2017

kbarton accepted D32763: [PPC] Lower load acquire/seq_cst trailing fence to cmp + bne + isync..

LGTM.
Thanks for adding the additional test case!

May 16 2017, 12:58 PM

May 12 2017

kbarton added inline comments to D32763: [PPC] Lower load acquire/seq_cst trailing fence to cmp + bne + isync..
May 12 2017, 12:55 PM

May 4 2017

kbarton accepted D32776: [PowerPC] Update branch coalescing to be a PowerPC specific pass.

Aside from two minor comments, this LGTM.
Please make sure to update the release notes when this gets committed.

May 4 2017, 8:04 PM
kbarton added inline comments to D32774: CodeGen: Power: Add lowering for shifts of v1i128..
May 4 2017, 7:55 PM
kbarton accepted D32781: [PowerPC] Implement vec_xxsldwi and vec_xxpermdi builtins - llvm portion..

Please add the PR that this problem is addressing to the summary.

May 4 2017, 7:49 PM
kbarton added a comment to D32762: [Atomic] Remove IsStore/IsLoad in the interface, and pass the instruction instead. NFC..

D32763 only handles the trailing fences. Is there going to be another patch that deals with the leading fences as well?

May 4 2017, 7:43 PM
kbarton added inline comments to D32763: [PPC] Lower load acquire/seq_cst trailing fence to cmp + bne + isync..
May 4 2017, 7:39 PM

Mar 1 2017

kbarton updated subscribers of D29750: [PPC] Enable -fomit-frame-pointer by default for PPC.
Mar 1 2017, 11:00 AM
kbarton updated subscribers of D29881: [PPC] Reduce stack frame size by allocating parameter area on an on-demand basis for ELFv2 ABI.
Mar 1 2017, 10:45 AM
kbarton updated subscribers of D30081: [PPC] Eliminate more compare instructions using record-form operation.
Mar 1 2017, 10:43 AM

Feb 8 2017

kbarton accepted D28249: Improve scheduling with branch coalescing.

Aside from a couple minor comments, this LGTM.

Feb 8 2017, 12:10 PM

Feb 1 2017

kbarton committed rL293769: [PowerPC] Fix sjlj pseduo instructions to use G8RC_NOX0 register class.
[PowerPC] Fix sjlj pseduo instructions to use G8RC_NOX0 register class
Feb 1 2017, 6:45 AM
kbarton closed D29289: [PowerPC] pseudo instruction EH_SjLj_LongJmp64 requires G8RC_NOX0 register by committing rL293769: [PowerPC] Fix sjlj pseduo instructions to use G8RC_NOX0 register class.
Feb 1 2017, 6:45 AM

Jan 13 2017

kbarton accepted D23630: [PPC] Expand ISEL instruction into if-then-else sequence.

Aside from updating two comments, this LGTM.

Jan 13 2017, 9:51 AM

Jan 11 2017

kbarton added inline comments to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.
Jan 11 2017, 11:27 AM

Jan 4 2017

kbarton added a comment to D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h.

Sorry, I don't have time to go through the entire patch in detail right now. But I did notice several places where the lines are too long, which need to get fixed.

Jan 4 2017, 12:03 PM
kbarton added a comment to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.

There are still a few things that need to get cleaned up.

Jan 4 2017, 11:51 AM

Dec 14 2016

kbarton added inline comments to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.
Dec 14 2016, 8:33 PM

Dec 1 2016

kbarton added a comment to D26817: [APFloat] Implement PPCDoubleDouble add and subtract..

I looked through this, but my review is mostly superficial as I don't have the background to be able to comment on the logic here.

Dec 1 2016, 10:01 AM
kbarton accepted D27231: [PowerPC] Fix logic dealing with nop after calls (and tail-call eligibility).

Aside from some minor comments, this LGTM.

Dec 1 2016, 9:33 AM
kbarton requested changes to D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h.

Please make explicit the signed for the parameters to the functions you are changing and remove unnecessary casts. I marked the first few that I found, but stopped marking them after the first several.

Dec 1 2016, 9:14 AM
kbarton requested changes to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.

Need to address Hal's comments and post a subsequent patch. Thanks.

Dec 1 2016, 8:16 AM
kbarton added a comment to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.

I've been thinking about how difficult it might be to handle the case where multiple isels use the same condition. I don't think it would be too difficult to support this: As you iterate through the isels in each block, keep track of the true block, false block and condition for the last expanded isel. If this isel has the same condition as the last one, then scan between them to make sure that nothing defines this isel's input registers in between the two isels and that this isel does not depend on the last one. If that's true, then insert the generated instructions into the blocks from the last isel instead of making new ones.

Dec 1 2016, 8:12 AM

Nov 22 2016

kbarton accepted D26546: [PPC] Add vec_insert4b/vec_extract4b to altivec.h.

LGTM, but I'd like @nemanjai to have a quick look at the builtin_vsx_insertword and builtin_vsx_extractuword too.

Nov 22 2016, 2:28 PM
kbarton accepted D26861: [POWERPC][LE] prevent vxs load and store from expanding to lxvd2x/xxswapd and xxswapd/stxvd2x for aligned vectors.

LGTM

Nov 22 2016, 10:53 AM

Nov 21 2016

kbarton requested changes to D23630: [PPC] Expand ISEL instruction into if-then-else sequence.

There are some things that need to get cleaned up.

Nov 21 2016, 1:32 PM
kbarton accepted D26066: [PowerPC] Improvements for BUILD_VECTOR Vol. 4.

LGTM

Nov 21 2016, 11:55 AM

Nov 18 2016

kbarton requested changes to D26861: [POWERPC][LE] prevent vxs load and store from expanding to lxvd2x/xxswapd and xxswapd/stxvd2x for aligned vectors.

The patterns for the int_ppc_vsx_lxvw4x and int_ppc_vsx_stxvw4x are still here.
These patterns should be intercepted and dealt with earlier, but if they are not they will match here and end up generating correct code. Can you please remove these patterns for LE. That way if they survive to this point, the program should fail to compile instead of generating incorrect code.

Nov 18 2016, 11:12 AM
kbarton accepted D26544: [PPC] support for arithmetic builtins in the FE.

LGTM

Nov 18 2016, 10:25 AM

Nov 15 2016

kbarton requested changes to D26066: [PowerPC] Improvements for BUILD_VECTOR Vol. 4.
Nov 15 2016, 3:17 PM