- User Since
- May 16 2014, 8:34 AM (430 w, 1 d)
May 16 2022
Looks very nice, thanks.
Mar 14 2022
On the high level note, using builtin_subc() or builtin_sub_with_overflow() is good enough workaround.
Feb 25 2022
Feb 23 2022
Feb 21 2022
This was intermediate change to solve https://github.com/llvm/llvm-project/issues/53432. There I want to merge sub + cmp into single sbb. Any suggestions how to solve it differently?
Feb 16 2022
Jan 28 2022
Jan 27 2022
Jan 26 2022
What I try to do in the end is to fix https://github.com/llvm/llvm-project/issues/53432. Maybe this particular change is not good direction, but on the other hand it also helps with the test add_U320_without_i128_add already in repo.
Jan 25 2022
Use switch. Rebased.
Address review comments.
What do you think about this idea in general? Can we assume or check if SETULT actually affects CL flag on given target?
Jan 24 2022
Jan 22 2022
I have noticed this post about undef/poison: https://llvm.discourse.group/t/evolution-of-undef-and-poison-over-time/5917/2.
Should I have added tests with poison instead of undef?
Jan 20 2022
@spatel, can you also review this?
Implemented extended variant which handles "active byte" at any position, suggested by @craig.topper.
I have found one case not covered by this case: in case of subtraction when we only care about the final carry bit (the difference is discarded) the first subtraction will be to compare. So here we may want to also search for cmp. I did a prototype by duplicating this code and modifying in for the cmp case only it this works. But I'm not sure if mixing it all here will be good idea. Anyway, I wanted to reach out about it and maybe fix the TODO from this patch in the mean time.
[InstCombine] Simplify bswap -> shift
Jan 19 2022
My motivation is rather boring. I have a generic data -> integer loader. The data is in big-endian order. For i32 example the data can be from 1 to 4 bytes in size. Here is the generic template which handles all 4 cases:
Jan 9 2022
Sep 14 2021
This change has very big impact on one of my projects. It looks like the effect should be positive as it reduces the code size, stack allocation and number of spills/reloads. Yet this decreases performance by ~6%. I'd like to understand why. The bug report is in https://bugs.llvm.org/show_bug.cgi?id=51857.
Feb 17 2021
Hey, I noticed that this does not always work for subtraction, probably due to canonicalization. See bug report: https://bugs.llvm.org/show_bug.cgi?id=49225.
Feb 1 2021
Nov 17 2020
This check can be useful in other case like this:
Sep 28 2020
Nov 19 2019
Nov 18 2019
Thanks for the update. Where is the original source for sub_U256_without_i128_or_recursive? The IR is strange. It seems to use two different strategies for merging carry flags.
I ended up with optimizing my bigint library. The end result is - add_U256_without_i128_or_recursive which works better in current LLVM release and is also nicely reduced by D70079.
The analogous implementations of subtraction is added as sub_U256_without_i128_or_recursive test. This one should be interested to you @davezarzycki, your changes make it better, but it looks it is not perfect yet.
Update addcarry tests and add a subcarry test
Nov 15 2019
Add comments more descriptive test names
Nov 14 2019
Oh sh*i, this is the same thing I'm doing in https://reviews.llvm.org/D70012.
Nov 8 2019
Sep 5 2019
Feb 7 2019
Another round of changes.
Feb 5 2019
Update unit tests.
Jan 3 2019
I did a small update.
Update with some intermidiate changes.