Page MenuHomePhabricator

rtereshin (Roman Tereshin)
Engineering

Projects

User does not belong to any projects.

User Details

User Since
Jan 9 2018, 11:39 AM (87 w, 4 d)

Recent Activity

Apr 18 2019

rtereshin added inline comments to D55851: Implement basic loop fusion pass.
Apr 18 2019, 4:30 PM · Restricted Project

Mar 14 2019

rtereshin accepted D59401: Fix non-determinism in Reassociate caused by address coincidences.

LGTM, please consider adding the following test:

Mar 14 2019, 9:07 PM · Restricted Project

Feb 26 2019

rtereshin abandoned D43962: [GlobalISel][utils] Adding the init version of Instruction Select Testgen.
Feb 26 2019, 9:12 AM · Restricted Project
Herald added a project to D43962: [GlobalISel][utils] Adding the init version of Instruction Select Testgen: Restricted Project.

Closing as we decided not to pursue this.

Feb 26 2019, 9:11 AM · Restricted Project

Feb 22 2019

rtereshin committed rG99a6672bba80: [LowerSwitch][AMDGPU] Do not handle impossible values (authored by rtereshin).
[LowerSwitch][AMDGPU] Do not handle impossible values
Feb 22 2019, 6:35 AM
rtereshin committed rL354670: [LowerSwitch][AMDGPU] Do not handle impossible values.
[LowerSwitch][AMDGPU] Do not handle impossible values
Feb 22 2019, 6:34 AM
rtereshin closed D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
Feb 22 2019, 6:34 AM · Restricted Project
rtereshin added a comment to D58500: [DO NOT MERGE] Explore MSSA behavior in LoopSimplifyCFG.

Shall we close this?

Feb 22 2019, 6:27 AM · Restricted Project
rtereshin added a comment to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.

Thank you!

Feb 22 2019, 6:19 AM · Restricted Project
rtereshin added a comment to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.

Is this good to go in?

Feb 22 2019, 4:23 AM · Restricted Project

Feb 20 2019

rtereshin added inline comments to D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 20 2019, 11:14 AM · Restricted Project

Feb 19 2019

rtereshin added inline comments to D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 19 2019, 6:50 PM · Restricted Project
rtereshin added inline comments to D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 19 2019, 6:00 PM · Restricted Project
rtereshin added inline comments to D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 19 2019, 4:52 PM · Restricted Project
rtereshin added a comment to D58098: [IR] Add Use::moveToFrontOfUseList() method.

This seems like it could be useful. Do you have specific places in mind where you'd take advantage of it?

Feb 19 2019, 4:33 PM · Restricted Project

Feb 18 2019

rtereshin added a comment to D58123: GlobalISel: Implement moreElementsVector for bit ops.

I've filed https://bugs.llvm.org/show_bug.cgi?id=40766 to track that.

Feb 18 2019, 2:24 PM
rtereshin accepted D58123: GlobalISel: Implement moreElementsVector for bit ops.

Thanks for addressing the comments.

Feb 18 2019, 1:51 PM
rtereshin added a reviewer for D58098: [IR] Add Use::moveToFrontOfUseList() method: dexonsmith.
Feb 18 2019, 1:37 PM · Restricted Project
rtereshin added a reviewer for D58101: Reapply "[CGP] Check for existing inttotpr before creating new one": hfinkel.
Feb 18 2019, 1:14 PM · Restricted Project
rtereshin added reviewers for D58098: [IR] Add Use::moveToFrontOfUseList() method: qcolombet, bogner.
Feb 18 2019, 11:00 AM · Restricted Project

Feb 16 2019

rtereshin added a reviewer for D58123: GlobalISel: Implement moreElementsVector for bit ops: qcolombet.
Feb 16 2019, 2:07 PM
rtereshin added a comment to D58123: GlobalISel: Implement moreElementsVector for bit ops.

Hi Matt,

Feb 16 2019, 2:02 PM

Feb 15 2019

rtereshin updated the diff for D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
  1. Addressed comments
  2. Refined the switch's operand constraints with known bits and added corresponding tests (all based on real-world cases)
Feb 15 2019, 3:12 AM · Restricted Project

Feb 14 2019

rtereshin added inline comments to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
Feb 14 2019, 11:07 PM · Restricted Project
rtereshin added inline comments to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
Feb 14 2019, 6:20 PM · Restricted Project
rtereshin added inline comments to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
Feb 14 2019, 5:57 PM · Restricted Project
rtereshin added a comment to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.

It seems weird to me that doing this somewhere else somehow ends up being more expensive, but this needs a comment somewhere explaining why it should be handled here

Feb 14 2019, 5:24 PM · Restricted Project
rtereshin added a comment to D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.

I'm not sure I see why LowerSwitch needs to worry about this optimization. Why doesn't SimplifyCFG or DCE or one of some other control flow optimization pass handle this so LowerSwitch doesn't have to worry about it?

Feb 14 2019, 11:28 AM · Restricted Project
rtereshin added a reviewer for D58096: [LowerSwitch][AMDGPU] Do not handle impossible values: marcello.maggioni.
Feb 14 2019, 11:28 AM · Restricted Project

Feb 12 2019

rtereshin added inline comments to D54468: [LoadStoreVectorizer] Fix infinite loop in reorder..
Feb 12 2019, 7:21 PM · Restricted Project

Feb 11 2019

rtereshin added a reviewer for D54468: [LoadStoreVectorizer] Fix infinite loop in reorder.: volkan.
Feb 11 2019, 11:43 PM · Restricted Project
rtereshin added child revisions for D58098: [IR] Add Use::moveToFrontOfUseList() method: D58100: [CGP] Replace MaxMemoryUsesToScan cut-off with Use::moveToFrontOfUseList(), D58101: Reapply "[CGP] Check for existing inttotpr before creating new one".
Feb 11 2019, 10:04 PM · Restricted Project
rtereshin added a parent revision for D58101: Reapply "[CGP] Check for existing inttotpr before creating new one": D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 11 2019, 10:04 PM · Restricted Project
rtereshin added a parent revision for D58100: [CGP] Replace MaxMemoryUsesToScan cut-off with Use::moveToFrontOfUseList(): D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 11 2019, 10:04 PM · Restricted Project
rtereshin created D58101: Reapply "[CGP] Check for existing inttotpr before creating new one".
Feb 11 2019, 10:03 PM · Restricted Project
rtereshin created D58100: [CGP] Replace MaxMemoryUsesToScan cut-off with Use::moveToFrontOfUseList().
Feb 11 2019, 9:48 PM · Restricted Project
rtereshin created D58098: [IR] Add Use::moveToFrontOfUseList() method.
Feb 11 2019, 9:28 PM · Restricted Project
rtereshin created D58096: [LowerSwitch][AMDGPU] Do not handle impossible values.
Feb 11 2019, 9:09 PM · Restricted Project
rtereshin accepted D58080: GlobalISel: Use default rounding mode when extending fconstant.
Feb 11 2019, 4:40 PM
rtereshin added a comment to D58080: GlobalISel: Use default rounding mode when extending fconstant.

I don't think this matters since the values should all be exactly representable.

Feb 11 2019, 4:21 PM

Feb 5 2019

rtereshin added a comment to D57243: GlobalISel: Allow bitcount ops to have different result type.

The type used in this case for the result has more to do with the type required for the operations after required for the legalization. The G_SUB can be done in either width, but the narrower sub seems like a more preferable canonical form.

Feb 5 2019, 11:50 AM
rtereshin added a comment to D57243: GlobalISel: Allow bitcount ops to have different result type.

Should we revert this change to have the conversation going or am I the only one unhappy with the absence of guarantees for the other operands?

Feb 5 2019, 11:03 AM

Feb 4 2019

rtereshin added inline comments to D57243: GlobalISel: Allow bitcount ops to have different result type.
Feb 4 2019, 4:13 PM
rtereshin updated subscribers of D57243: GlobalISel: Allow bitcount ops to have different result type.
Feb 4 2019, 3:49 PM
rtereshin added inline comments to D57243: GlobalISel: Allow bitcount ops to have different result type.
Feb 4 2019, 1:14 PM

Jan 18 2019

rtereshin committed rL351626: Reapply "[CGP] Check for existing inttotpr before creating new one".
Reapply "[CGP] Check for existing inttotpr before creating new one"
Jan 18 2019, 7:43 PM
rtereshin committed rL351619: Revert "Reapply "[CGP] Check for existing inttotpr before creating new one"".
Revert "Reapply "[CGP] Check for existing inttotpr before creating new one""
Jan 18 2019, 5:58 PM
rtereshin committed rL351618: Reapply "[CGP] Check for existing inttotpr before creating new one".
Reapply "[CGP] Check for existing inttotpr before creating new one"
Jan 18 2019, 5:45 PM
rtereshin committed rL351598: Revert "[CGP] Check for existing inttotpr before creating new one".
Revert "[CGP] Check for existing inttotpr before creating new one"
Jan 18 2019, 1:43 PM
rtereshin committed rL351582: [CGP] Check for existing inttotpr before creating new one.
[CGP] Check for existing inttotpr before creating new one
Jan 18 2019, 12:19 PM
rtereshin closed D56838: [CGP] Check for existing inttotpr before creating new one.
Jan 18 2019, 12:19 PM

Jan 17 2019

rtereshin added a comment to D56838: [CGP] Check for existing inttotpr before creating new one.

Can we run EarlyCSE after CGP (instead of trying to do these kinds of point fixes)?

Hi Hal,

Thank you for looking into this!

That's a great suggestion! Originally I just eyeballed it as too expensive compile-time wise for the little effect that is achieved here.

This time around with you pointing it out, I performed the actual measurements for a very large suite of shaders (the downstream target in question is a GPU). I see about 1.0 (+/-0.3)% increase in overall compile time (the part of it that happens at an application run-time) on average. The generated code quality improvement that comes out of this may be important, but it doesn't trigger often enough to justify 1% compile time increase across the board.

Thanks,
Roman

Fair enough. Thanks for checking.

I have a comment about the test case, but otherwise LGTM.

Jan 17 2019, 10:52 PM
rtereshin updated the diff for D56838: [CGP] Check for existing inttotpr before creating new one.

Updated the test as requested

Jan 17 2019, 10:52 PM
rtereshin added reviewers for D56838: [CGP] Check for existing inttotpr before creating new one: bogner, hfinkel.
Jan 17 2019, 4:26 PM
rtereshin added a comment to D56838: [CGP] Check for existing inttotpr before creating new one.

Can we run EarlyCSE after CGP (instead of trying to do these kinds of point fixes)?

Jan 17 2019, 4:26 PM
rtereshin created D56838: [CGP] Check for existing inttotpr before creating new one.
Jan 17 2019, 2:58 AM

Oct 31 2018

rtereshin accepted D53189: [SCEV] Avoid redundant computations when doing AddRec merge.

Do you think it's better to remove the NFC tag from the patch? It doesn't look like it's completely NFC, though, I've tested this out for a major (though, out of tree) GPU target on a very large suite of shaders and found no difference.

Oct 31 2018, 12:52 PM
rtereshin accepted D53447: [adt] SparseBitVector::test() should be const.

LGTM, thanks for doing this!

Oct 31 2018, 10:34 AM

Oct 19 2018

rtereshin committed rL344822: [MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again).
[MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again)
Oct 19 2018, 5:08 PM
rtereshin closed D53144: [MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again).
Oct 19 2018, 5:08 PM

Oct 15 2018

rtereshin added inline comments to D53144: [MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again).
Oct 15 2018, 3:21 PM

Oct 11 2018

rtereshin created D53144: [MachineCSE][GlobalISel] Making sure MachineCSE works mid-GlobalISel (again).
Oct 11 2018, 10:10 AM

Aug 30 2018

rtereshin added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

I would tend to think that when we create instruction with constant we can discipline ourselves for not putting them on the LHS.

Aug 30 2018, 8:57 AM

Aug 29 2018

rtereshin added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

I'm not against a separate IR canonicalization stage, even though it's a bit overkill for this particular case. At the moment it looks like InstCombine is doing the canonicalizaton for this case, so re-running that is out of the question. A new pass looks to be on the cards. Anyone else have opinions on this?

Does that mean that something after the last InstCombine produces icmp's with the non-canonical operand order? If so maybe that something needs to be chased down and fixed instead.

Aug 29 2018, 3:55 PM
rtereshin added a comment to D51362: [GlobalISel][IRTranslator] Canonicalize G_ICMP to have constant operands last.

I'm not against a separate IR canonicalization stage, even though it's a bit overkill for this particular case. At the moment it looks like InstCombine is doing the canonicalizaton for this case, so re-running that is out of the question. A new pass looks to be on the cards. Anyone else have opinions on this?

Aug 29 2018, 3:41 PM

Aug 27 2018

rtereshin added inline comments to D40645: [SCEV][NFC] Check NoWrap flags before lexicographical comparison of SCEVs.
Aug 27 2018, 2:49 PM
rtereshin committed rL340777: Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of….
Revert "[SCEV][NFC] Check NoWrap flags before lexicographical comparison of…
Aug 27 2018, 2:42 PM

Aug 24 2018

rtereshin added a comment to D50985: [SCEV] LoopsUsed memoization.

Hi Maxim,

Aug 24 2018, 9:52 AM

Aug 20 2018

rtereshin created D51014: [SCEV] Compare SCEVs by a complexity rank before lexic-al comparison.
Aug 20 2018, 4:44 PM
rtereshin created D50985: [SCEV] LoopsUsed memoization.
Aug 20 2018, 11:41 AM

Aug 17 2018

rtereshin accepted D48847: [GISel]: Add Legalization/lowering code for bit counting operations.

Thank you!

Aug 17 2018, 4:24 PM

Aug 14 2018

rtereshin added a comment to D48847: [GISel]: Add Legalization/lowering code for bit counting operations.

Hi Aditya,

Aug 14 2018, 11:19 AM

Aug 10 2018

rtereshin added inline comments to D40645: [SCEV][NFC] Check NoWrap flags before lexicographical comparison of SCEVs.
Aug 10 2018, 5:13 PM

Aug 3 2018

rtereshin added inline comments to D50272: [tablegen] Improve performance of -gen-register-info by replacing barely-necessary std::map with a sorted vector.
Aug 3 2018, 9:26 PM
rtereshin accepted D50272: [tablegen] Improve performance of -gen-register-info by replacing barely-necessary std::map with a sorted vector.

LGTM with minor nitpicks, please feel free to make changes you'll find reasonable while committing.

Aug 3 2018, 9:13 PM
rtereshin requested changes to D50272: [tablegen] Improve performance of -gen-register-info by replacing barely-necessary std::map with a sorted vector.

This is an impressive result, thanks for doing this!

Aug 3 2018, 3:51 PM

Aug 2 2018

rtereshin accepted D48600: [GISel]:Add Opcodes for CTLZ/CTTZ/CTPOP.

LGTM

Aug 2 2018, 3:48 PM

Aug 1 2018

rtereshin accepted D49660: [GlobalISel] Rewrite CallLowering::lowerReturn to accept multiple VRegs per Value.

Hi Roman, I would prefer to do it as separate patches: the first one for Value splitting routine and the second for one splitToValueTypes

Aug 1 2018, 5:12 PM
rtereshin added a comment to D49660: [GlobalISel] Rewrite CallLowering::lowerReturn to accept multiple VRegs per Value.

Hi Alexander,

Aug 1 2018, 10:12 AM

Jul 30 2018

rtereshin accepted D49900: [GlobalISel] Add a G_BLOCK_ADDR opcode to handle IR blockaddress constants..

Besides a nitpick, LGTM

Jul 30 2018, 10:52 AM
rtereshin accepted D49902: [AArch64][GlobalISel] Make G_BLOCK_ADDR legal.
Jul 30 2018, 10:16 AM

Jul 26 2018

rtereshin added inline comments to D49660: [GlobalISel] Rewrite CallLowering::lowerReturn to accept multiple VRegs per Value.
Jul 26 2018, 12:35 PM

Jul 25 2018

rtereshin committed rL337965: [LSV] Look through selects for consecutive addresses.
[LSV] Look through selects for consecutive addresses
Jul 25 2018, 2:33 PM
rtereshin closed D49428: [LSV] Look through selects for consecutive addresses.
Jul 25 2018, 2:33 PM
rtereshin added a comment to D49428: [LSV] Look through selects for consecutive addresses.

LGTM

Jul 25 2018, 2:32 PM
rtereshin updated the diff for D49428: [LSV] Look through selects for consecutive addresses.
  1. Renamed MaxRecurse to Depth as requested and updated the logic around it as MaxRecurse was going from the positive limit down to 0 which makes no sense for a parameter called Depth, so Depth is going from 0 to MaxDepth now.
  2. Renamed RecursionLimit to MaxDepth to make the connection with Depth parameter clearer (which was MaxRecurse previously).
Jul 25 2018, 2:21 PM
rtereshin added inline comments to D49428: [LSV] Look through selects for consecutive addresses.
Jul 25 2018, 2:05 PM
rtereshin committed rL337943: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.
[SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform
Jul 25 2018, 11:02 AM

Jul 24 2018

rtereshin added inline comments to D49428: [LSV] Look through selects for consecutive addresses.
Jul 24 2018, 4:00 PM
rtereshin updated the diff for D49428: [LSV] Look through selects for consecutive addresses.
  1. Added comments explaining partitioning of memory access instructions into groups of candidates for better performance
  2. Added curly braces
Jul 24 2018, 4:00 PM
rtereshin committed rL337859: [SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw><nsw> transform.
[SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw><nsw> transform
Jul 24 2018, 2:49 PM
rtereshin closed D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.
Jul 24 2018, 2:49 PM
rtereshin added a comment to D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.

Yes, looks fine.

Jul 24 2018, 2:40 PM
rtereshin added a comment to D49428: [LSV] Look through selects for consecutive addresses.

Hi Matt,

Jul 24 2018, 11:15 AM
rtereshin added a comment to D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.

I think if we're going to do this, we need to implement it on top of a SCEV-based known-bits implementation; introducing a separate getZeroExtendExprForValue API is going to lead to weird results if SCEV creates a zero-extend expression for some other reason.

Whether we should do this in general, I'm not really sure. I mean, yes, I can see how this particular form is a bit more convenient for the load-store vectorizer, but it doesn't seem very general; it seems more intuitive to canonicalize towards reducing the number of AddExprs. But maybe pulling as much information as possible outside of the zext is generally useful enough to make this worthwhile?

Do you also plan to implement a similar transform for AddRecs? (e.g. (zext i32 {1,+,2}<%while.body> to i64)).

Jul 24 2018, 11:13 AM

Jul 20 2018

rtereshin updated the diff for D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.

Removed an out of place comment (the example comparing ConstantRange and KnownBits)

Jul 20 2018, 4:27 PM
rtereshin committed rL337606: Reapply "[LSV] Refactoring + supporting bitcasts to a type of different size".
Reapply "[LSV] Refactoring + supporting bitcasts to a type of different size"
Jul 20 2018, 1:15 PM

Jul 19 2018

rtereshin added inline comments to D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.
Jul 19 2018, 6:29 PM
rtereshin updated the diff for D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.

Updated and added comments as requested, renamed FullExpr to WholeAddExpr, and planned to add the following piece to the end of the commit message:

Jul 19 2018, 5:38 PM
rtereshin added inline comments to D48853: [SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform.
Jul 19 2018, 4:24 PM