- User Since
- Jul 24 2016, 1:28 AM (234 w, 4 d)
Thu, Dec 31
Why is discussion about gepi coming up at all?
Oct 25 2020
Oct 18 2020
Is there anything I could do to make this proceed?
Oct 4 2020
Pass around DAGCombinerInfo instead of booleans
Rebase on top of D88785
Oct 3 2020
The build error appears to be unrelated to the changes here – other differentials fail in much the same way.
Don't force lowering of weird xors for aarch64
Dont attempt to force legalization of non-trivial ops
Sep 28 2020
Restore i128-sdiv further
restore i128-sdiv RUN lines
Gate lowering on whether we're after type lowering & rebase
Sep 27 2020
Sep 26 2020
Don't do any of this after legalization has already happend
Aug 29 2020
Mar 3 2019
Nov 17 2018
Aug 22 2018
You also want to add some people as reviewers (possibly based on a blame of the file), otherwise the patch might go by unnoticed.
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.
The minimal test case you added to the bug report should be fine.
Please add a test. See this.
Aug 13 2018
Aug 10 2018
Updated test filenames to better reflect what they are testing.
Aug 8 2018
Aug 7 2018
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 6 2018
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 5 2018
Nov 26 2017
Would be nice if somebody committed this. None of us have the commit bit.
Jan 27 2017
When can I expect this to land into the trunk?
Jan 24 2017
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
please double check all the ABIs here
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 22 2017
Make alignment changes specific to 64-bit targets.
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.
Does this affects also bigger types like i256?
Oct 4 2016
No time/mood to pursue this further. Feel free to take over.
Aug 30 2016
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.
This still wants a review, especially regarding the cmake particularities.
Aug 15 2016
@echristo I would really appreciate a review.
Jul 24 2016
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.