Page MenuHomePhabricator

alexsusu (Alex Susu)
User

Projects

User does not belong to any projects.

User Details

User Since
Sep 7 2017, 2:57 AM (117 w, 9 h)

Recent Activity

May 6 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

Added relevant tests in test/CodeGen/Connex.

May 6 2019, 3:53 PM · Restricted Project

May 3 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

Addressed most reviews of efriedma, arsenm, luismarques (and of asb).

May 3 2019, 3:15 PM · Restricted Project

Apr 25 2019

alexsusu added a comment to D60052: Add Connex vector processor back end.
Apr 25 2019, 4:11 PM · Restricted Project

Apr 22 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

Added all required files for the back end (a few were missing).

Apr 22 2019, 6:12 PM · Restricted Project

Apr 20 2019

alexsusu added a comment to D60052: Add Connex vector processor back end.
In D60052#1471560, @asb wrote:

Some initial feedback:

  • This patch is pretty huge which makes it pretty hard to meaningfully review
  • There seem to be effectively no tests. I'd expect test/CodeGen/Connex and test/MC/Connex to be reasonably well populated
  • Plenty of code commented out or with date-based comments that don't match our style, e.g. // 2018_*
  • Files have the old license header rather than the new one
Apr 20 2019, 7:50 PM · Restricted Project

Apr 19 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

Made a first round of corrections following Alex Bradbury's review.

Apr 19 2019, 6:09 PM · Restricted Project

Apr 15 2019

alexsusu updated the summary of D60052: Add Connex vector processor back end.
Apr 15 2019, 5:09 PM · Restricted Project
alexsusu updated the diff for D60052: Add Connex vector processor back end.

Added myself as maintainer of the Connex backend in CODE_OWNERS.TXT.

Apr 15 2019, 3:11 PM · Restricted Project
alexsusu updated the diff for D60052: Add Connex vector processor back end.

Added all source files for the Connex back end.
Followed coding standards from https://llvm.org/docs/CodingStandards.html .

Apr 15 2019, 1:49 PM · Restricted Project

Apr 13 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

More refactoring on the .td TableGen files. Added also more source files.

Apr 13 2019, 4:46 PM · Restricted Project

Apr 12 2019

alexsusu updated the summary of D60052: Add Connex vector processor back end.
Apr 12 2019, 8:11 PM · Restricted Project
alexsusu updated the summary of D60052: Add Connex vector processor back end.
Apr 12 2019, 7:54 PM · Restricted Project
alexsusu updated the summary of D60052: Add Connex vector processor back end.
Apr 12 2019, 7:39 PM · Restricted Project
alexsusu updated the summary of D60052: Add Connex vector processor back end.
Apr 12 2019, 7:38 PM · Restricted Project
alexsusu updated the diff for D60052: Add Connex vector processor back end.

A few corrections to ConnexInstrInfoVec.td .

Apr 12 2019, 3:41 PM · Restricted Project

Apr 1 2019

alexsusu updated the diff for D60052: Add Connex vector processor back end.

Added 2 more files. I still have to add another about 50 files.

Apr 1 2019, 4:41 PM · Restricted Project

Mar 31 2019

alexsusu updated the summary of D60052: Add Connex vector processor back end.
Mar 31 2019, 6:19 PM · Restricted Project
alexsusu created D60052: Add Connex vector processor back end.
Mar 31 2019, 5:17 PM · Restricted Project

Oct 25 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Addressed small review issue of greened (David Greene) on comment in method: void visitAddRecExpr(const SCEVAddRecExpr *Numerator) .

Oct 25 2018, 2:18 AM

Jul 25 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Did corrections, following Dave Green's comments.

Jul 25 2018, 11:51 AM

Jul 13 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Made a better patch following comments from Michael Kruse.
Most importantly I added comments that I consider SCEVDivision::divide() to be signed division.

Jul 13 2018, 5:33 AM

Jun 6 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Addressed Michael Kruse's comment on the patch - changed the test .ll file.

Jun 6 2018, 11:25 PM
alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Adding, as Roman suggested, in the header of the test_sext.ll file a line describing the RUN command and a CHECK line.

Jun 6 2018, 2:02 PM
alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Adding as Roman said the patch for ScalarEvolution.cpp and also the associated test test/Analysis/Delinearization/test_sext.ll .

Jun 6 2018, 12:32 PM

May 2 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).
Added correct path to the ScalarEvolution.cpp file (lib/Analysis/ScalarEvolution.cpp).
Again, my patch incorporates also the one from https://reviews.llvm.org/D35478 - in order to make it work well for SCEVDivision, when having SExt expressions. My own changes are basically only the ones handling SCEVSignExtendExpr.
May 2 2018, 1:48 PM

Apr 30 2018

alexsusu updated the diff for D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Note that in this patch we only address the SExt, as suggested by Michael (Meinersbur).

Apr 30 2018, 2:12 PM

Mar 19 2018

alexsusu added a comment to D40369: Support sext instruction in SCEV delinearization algorithm (new revision).

Adding very simple unit tests on which normally Polly fails to detect the right SCoP due to the sext (and trunc, as well) in both dividend and divisor used in the third step of the delinearization algorithm (it seems the SCEV expressions sext(N * N), sext(N), etc are created by the 1st step of the delinearization algorithm extracting the terms from the sum of products from the array index i * N * N + j * N + k) presented in Section 4.1 of the paper Grosser et al, "On recovering Multi-dimensional Arrays in Polly", IMPACT 2015 - http://impact.gforge.inria.fr/impact2015/papers/impact2015-grosser.pdf ). Because of this Polly complains of non-affine expression for array indexing.
To make Polly work, we need to apply the patch I already committed (I will put another patch ASAP).
Please note my patch is not incremental w.r.t. patch from https://reviews.llvm.org/D35478 - you need to apply ONLY my patch.

Mar 19 2018, 2:38 PM

Jan 18 2018

alexsusu retitled D42142: [Polly] [WIP] Adding Live-Range Reordering for Polly from Adding Live-range reordering for Polly to [Polly] [WIP] Adding Live-Range Reordering for Polly.
Jan 18 2018, 6:38 AM

Jan 16 2018

alexsusu created D42142: [Polly] [WIP] Adding Live-Range Reordering for Polly.
Jan 16 2018, 4:04 PM

Nov 22 2017

alexsusu added a child revision for D35478: Support sext and trunc instructions in SCEV delinearization algorithm: D40369: Support sext instruction in SCEV delinearization algorithm (new revision).
Nov 22 2017, 11:08 AM · Restricted Project
alexsusu added a parent revision for D40369: Support sext instruction in SCEV delinearization algorithm (new revision): D35478: Support sext and trunc instructions in SCEV delinearization algorithm.
Nov 22 2017, 11:08 AM
alexsusu created D40369: Support sext instruction in SCEV delinearization algorithm (new revision).
Nov 22 2017, 11:06 AM

Oct 18 2017

alexsusu added a comment to D38953: Updating the TipsAndTricks.rst documentation of Polly related to bugpoint.

Thanks for improving our documentation!

Oct 18 2017, 4:04 AM · Restricted Project

Oct 16 2017

alexsusu added a comment to D35478: Support sext and trunc instructions in SCEV delinearization algorithm.

Hello.

I applied the patch that was provided in this review to my LLVM build.
I would like to draw attention to a bug of the deliniarization procedure that is related to type casts (from i32 to i64), and is probably related to the problems that were supposed to be addressed by the patch in this review.
I attach a C file that reproduces this bug - the delinearization procedure fails due to sext from i32 to i64, and Polly finds Non affine access functions, which he shouldn't. Note that in the same C file I also provide on line 3 a commented signature of the Test function which can be uncommented, for which delinearization works OK and all access functions are affine.
I will try to look deeper in the problem with delinearization. Please let me know if you can help with this problem.

Best regards,

Alex
Oct 16 2017, 1:39 PM · Restricted Project
alexsusu updated the diff for D38953: Updating the TipsAndTricks.rst documentation of Polly related to bugpoint.

(nothing serious, part 2)

Oct 16 2017, 8:01 AM · Restricted Project
alexsusu updated the diff for D38953: Updating the TipsAndTricks.rst documentation of Polly related to bugpoint.

(nothing serious)

Oct 16 2017, 7:59 AM · Restricted Project
alexsusu created D38953: Updating the TipsAndTricks.rst documentation of Polly related to bugpoint.
Oct 16 2017, 7:05 AM · Restricted Project

Oct 13 2017

alexsusu added a comment to D35478: Support sext and trunc instructions in SCEV delinearization algorithm.

Hi Tobias,

Thank you for looking at that. To first answer your questions "out of interest", this IR is generated by JavaScriptCore, a JavaScript virtual machine performing JIT compilation. The virtual machine is using NaN-boxing, i.e., uses the unused values (all representing NaN) of 64 bits floating point representation to represent JavaScript objects. In this representation, 32 bits integers are represented by 64 bits values all starting with the FFFF 0000 32 bits pattern. As a consequence, to get the integer value from a 64 bits value, the virtual machine generates LLVM code that truncates the value to a 32 bits integer.

Then, when performing arithmetic operations on these 32 bits integers, we need to ensure that they do not overflow, because if it's the case, we can't represent them anymore with the NaN-boxing trick and so we need to do *something* to represent them properly. This "something" is not present in the test case I provided in order to make it as minimal as possible.

If you are curious on this NaN-boxing thing and more generally on JavaScript implementations, you can have a look at the following links:

Oct 13 2017, 12:47 PM · Restricted Project