Page MenuHomePhabricator

nagisa (Simonas Kazlauskas)
User

Projects

User does not belong to any projects.

User Details

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

Recent Activity

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