Page MenuHomePhabricator

nagisa (Simonas Kazlauskas)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 24 2016, 1:28 AM (227 w, 5 d)

Recent Activity

Oct 25 2020

nagisa updated the summary of D88785: Support {S,U}REMEqFold before legalization.
Oct 25 2020, 8:36 AM · Restricted Project

Oct 18 2020

nagisa added a comment to D88785: Support {S,U}REMEqFold before legalization.

Is there anything I could do to make this proceed?

Oct 18 2020, 2:28 PM · Restricted Project

Oct 4 2020

nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

Pass around DAGCombinerInfo instead of booleans

Oct 4 2020, 7:09 AM · Restricted Project
nagisa updated the summary of D87976: Support the division-by-constant strength reduction for more integer types.
Oct 4 2020, 6:34 AM · Restricted Project
nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

Rebase on top of D88785

Oct 4 2020, 6:34 AM · Restricted Project

Oct 3 2020

nagisa added a comment to D88785: Support {S,U}REMEqFold before legalization.

The build error appears to be unrelated to the changes here – other differentials fail in much the same way.

Oct 3 2020, 6:03 PM · Restricted Project
nagisa updated the summary of D88785: Support {S,U}REMEqFold before legalization.
Oct 3 2020, 1:19 PM · Restricted Project
nagisa updated the diff for D88785: Support {S,U}REMEqFold before legalization.

Don't force lowering of weird xors for aarch64

Oct 3 2020, 1:11 PM · Restricted Project
nagisa added inline comments to D88785: Support {S,U}REMEqFold before legalization.
Oct 3 2020, 1:09 PM · Restricted Project
nagisa updated the diff for D88785: Support {S,U}REMEqFold before legalization.

Dont attempt to force legalization of non-trivial ops

Oct 3 2020, 12:49 PM · Restricted Project
nagisa updated the summary of D88785: Support {S,U}REMEqFold before legalization.
Oct 3 2020, 11:37 AM · Restricted Project
nagisa requested review of D88785: Support {S,U}REMEqFold before legalization.
Oct 3 2020, 11:33 AM · Restricted Project
nagisa added inline comments to D87976: Support the division-by-constant strength reduction for more integer types.
Oct 3 2020, 9:49 AM · Restricted Project

Sep 28 2020

nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

Restore i128-sdiv further

Sep 28 2020, 4:23 AM · Restricted Project
nagisa added inline comments to D87976: Support the division-by-constant strength reduction for more integer types.
Sep 28 2020, 4:22 AM · Restricted Project
nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

restore i128-sdiv RUN lines

Sep 28 2020, 4:21 AM · Restricted Project
nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

redo formatting

Sep 28 2020, 4:19 AM · Restricted Project
nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

Gate lowering on whether we're after type lowering & rebase

Sep 28 2020, 4:15 AM · Restricted Project

Sep 27 2020

nagisa added a comment to D87976: Support the division-by-constant strength reduction for more integer types.

I'm skeptical this is a good idea when the division is wider than the widest legal mulhi. You end up generating either a ton of inline code, or a libcall; the result might not be faster than the original divide libcall.

Sep 27 2020, 3:04 PM · Restricted Project
nagisa added inline comments to D87976: Support the division-by-constant strength reduction for more integer types.
Sep 27 2020, 5:04 AM · Restricted Project

Sep 26 2020

nagisa updated the diff for D87976: Support the division-by-constant strength reduction for more integer types.

Don't do any of this after legalization has already happend

Sep 26 2020, 6:18 PM · Restricted Project
nagisa published D87976: Support the division-by-constant strength reduction for more integer types for review.
Sep 26 2020, 5:43 PM · Restricted Project

Aug 29 2020

nagisa resigned from D34285: [SROA] Be smarter when copying metadata to retyped loads.
Aug 29 2020, 8:07 AM
nagisa resigned from D36588: [ValueTracking] don't delete assumes of side-effectful instructions.
Aug 29 2020, 8:07 AM

Mar 3 2019

nagisa added inline comments to D58881: [Transform] Improve fold of sadd.with.overflow.
Mar 3 2019, 3:03 AM · Restricted Project

Nov 17 2018

nagisa added inline comments to D54666: [InstCombine] Simplify funnel shifts based on demanded bits.
Nov 17 2018, 8:18 AM

Aug 22 2018

nagisa added a comment to D51108: [PowerPC] Fix wrong ABI for i1 stack arguments on PPC32.

You also want to add some people as reviewers (possibly based on a blame of the file), otherwise the patch might go by unnoticed.

Aug 22 2018, 10:10 AM
nagisa added a comment to D50791: [SelectionDAG] unroll unsupported vector FP ops earlier to avoid libcalls on undef elements (PR38527).

The changes to tests seem fine to me. I don’t see why this behaviour would be incompatible with a future change to add support for SVML & friends at selection/legalisation time.

Aug 22 2018, 10:02 AM
nagisa added a comment to D51108: [PowerPC] Fix wrong ABI for i1 stack arguments on PPC32.

The minimal test case you added to the bug report should be fine.

Aug 22 2018, 10:00 AM
nagisa added a comment to D51108: [PowerPC] Fix wrong ABI for i1 stack arguments on PPC32.

Please add a test. See this.

Aug 22 2018, 9:59 AM

Aug 13 2018

nagisa added a comment to D50310: Improve the legalisation lowering of UMULO.

Do you want me to commit this for you?

Aug 13 2018, 9:37 PM

Aug 10 2018

nagisa updated the diff for D50310: Improve the legalisation lowering of UMULO.

Updated test filenames to better reflect what they are testing.

Aug 10 2018, 10:04 AM

Aug 8 2018

nagisa added a comment to D50310: Improve the legalisation lowering of UMULO.

Please choose a different name for the tests; "muloti2.ll" isn't usefully indicating what the files actually test.

Aug 8 2018, 1:42 PM

Aug 7 2018

nagisa updated the diff for D50310: Improve the legalisation lowering of UMULO.

Changed code to use BUILD_PAIR;
Added the tests for i64 umulo;
Moved the AArch tests to the right places;
Added a Thumbv6 i128 umulo test.

Aug 7 2018, 11:33 AM
nagisa added inline comments to D50310: Improve the legalisation lowering of UMULO.
Aug 7 2018, 3:40 AM
nagisa added a comment to D50310: Improve the legalisation lowering of UMULO.

No tests for umul.with.overflow.i64 on 32-bit?

Aug 7 2018, 3:31 AM

Aug 6 2018

nagisa updated the diff for D50310: Improve the legalisation lowering of UMULO.

I’ve added some codegen tests. Those just ensure that targets are able to lower this operation more than anything else, although I did manually verify the x64 assembly to check whether it really looks like what I expect.

Aug 6 2018, 1:51 PM

Aug 5 2018

nagisa updated the summary of D50310: Improve the legalisation lowering of UMULO.
Aug 5 2018, 8:02 AM
nagisa created D50310: Improve the legalisation lowering of UMULO.
Aug 5 2018, 8:00 AM

Nov 26 2017

nagisa added a comment to D37216: [SROA] propagate !range metadata when moving loads.

Would be nice if somebody committed this. None of us have the commit bit.

Nov 26 2017, 1:01 AM

Jan 27 2017

nagisa added a comment to D28990: Align i128 to 16 bytes.

When can I expect this to land into the trunk?

Jan 27 2017, 1:43 PM

Jan 24 2017

nagisa added a comment to D28990: Align i128 to 16 bytes.

This is for ARM: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055c/IHI0055C_beta_aapcs64.pdf;
This is for x64: https://msdn.microsoft.com/en-us/library/zthk2dkh.aspx (protip: needs careful reading because __int128 is not supported by MSVC directly and is not explicitly mentioned by the docs, but wording is unambiguous enough to make conclusions);
SPARC (https://docs.oracle.com/cd/E26502_01/pdf/E28387.pdf) does not mention anything really and there’s some encryption involving “slots” and whatnot in that document, but

Jan 24 2017, 5:32 PM
nagisa added a comment to D28990: Align i128 to 16 bytes.

please double check all the ABIs here

Jan 24 2017, 4:23 PM
nagisa added a comment to D28990: Align i128 to 16 bytes.

Its as @majnemer says, 16-byte alignment is required by ABI. Not just targets which use SysV, but any, where int128 is supported, because clang hardcodes int128 to have alignment of 16-bytes on *all* targets.

Jan 24 2017, 3:35 PM

Jan 22 2017

nagisa updated the diff for D28990: Align i128 to 16 bytes.

Make alignment changes specific to 64-bit targets.

Jan 22 2017, 10:38 AM
nagisa added a comment to D28990: Align i128 to 16 bytes.

At least for some x86 targets, this will unncessarily penalize the stack. Don't know all the other 32bit architectures, but many of those don't have a stack alignment larger than 32bit either.

Jan 22 2017, 10:07 AM
nagisa added a comment to D28990: Align i128 to 16 bytes.

Does this affects also bigger types like i256?

Jan 22 2017, 7:20 AM
nagisa created D28990: Align i128 to 16 bytes.
Jan 22 2017, 6:19 AM

Oct 4 2016

nagisa abandoned D22736: Make LLVMInitializeAll* API have their symbols.

No time/mood to pursue this further. Feel free to take over.

Oct 4 2016, 5:52 AM

Aug 30 2016

nagisa added a comment to D22736: Make LLVMInitializeAll* API have their symbols.

I built this on MSVC today (cmake $PATH_TO_LLVM && double-click LLVM.sln && initiate the build in MSVC) and it built (seemingly) whole of LLVM successfully, but ended failing at some ADT/ArrayRef tests due to missing declarations or definitions (something about .contains() not being present on some type etc), which seem to be unrelated to this patch.

Aug 30 2016, 12:26 PM
nagisa added a comment to D22736: Make LLVMInitializeAll* API have their symbols.

This still wants a review, especially regarding the cmake particularities.

Aug 30 2016, 5:44 AM

Aug 15 2016

nagisa added a comment to D22736: Make LLVMInitializeAll* API have their symbols.

@echristo I would really appreciate a review.

Aug 15 2016, 5:42 AM

Jul 24 2016

nagisa retitled D22736: Make LLVMInitializeAll* API have their symbols from to Make LLVMInitializeAll* API have their symbols.
Jul 24 2016, 8:43 AM
nagisa updated the diff for D22734: Make LLVMInitializeAll* API have their symbols.

I updated the thing to build another library libLLVMAllTargets (bikeshed on library name or placement welcome) and confirmed that the bin directory doesn’t get much larger with this change. I also confirmed by hand that libLLVM-4.0svn.so now contains said symbols.

Jul 24 2016, 5:35 AM
nagisa added inline comments to D22734: Make LLVMInitializeAll* API have their symbols.
Jul 24 2016, 2:40 AM
nagisa added a comment to D22734: Make LLVMInitializeAll* API have their symbols.

@nagisa, they are deliberately inline and deliberately unavailable for FFI use. After your change, every single executable statically linking to Target will link every individual backend, which makes them at least 200-500MB larger and increases link times by 10-60s (ballpark numbers).

Jul 24 2016, 2:38 AM
nagisa retitled D22734: Make LLVMInitializeAll* API have their symbols from to Make LLVMInitializeAll* API have their symbols.
Jul 24 2016, 1:30 AM