Looks very nice, thanks.

In D56214#3377947, @RKSimon wrote:

@chfast What happened to this patch? I was looking at https://llvm.org/PR36243 and wondering if it'd be worth AggressiveInstCombine/InstCombine doing something similar for adds (in that case a 3 chain add i32 to add i96).

On the high level note, using builtin_subc() or builtin_sub_with_overflow() is good enough workaround.

In D118037#3377941, @RKSimon wrote:

@chfast reverse-ping - any luck with working out how best to deal with add_U320_without_i128_add?

Rebased.

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?

In D118037#3294363, @RKSimon wrote:

Maybe perform this inside X86ISelLowering?

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.

In D118037#3272270, @RKSimon wrote:

BTW - how come we still have the ISD::ADDE/SUBE nodes? I thought we were intending to get rid of them as the glue nodes made them difficult to work with.

In D118037#3272185, @lebedev.ri wrote:

Is ISD::SETULT documented as affecting carry flag?

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?

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?

Trigger rebuild.

@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.

In D117680#3255155, @craig.topper wrote:

Can we do computeKnownBits().countMaxActiveBits() <= 8 -> replace with shl. If (BitWidth - computeKnownBits().countMaxTrailingZeros()) <= 8 -> replace with lshr?

[InstCombine] Simplify bswap -> shift

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:
https://godbolt.org/z/dPcGjvb94

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.

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.

This check can be useful in other case like this:

Thanks for comments @deadalnix, but please review D70079. I'm closing this one as being the duplicate of the mentioned PR.

Fix typo

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.

Remove URLs

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

In D70237#1747220, @davezarzycki wrote:

Yes, please update subcarry.ll too.

In D70237#1745687, @davezarzycki wrote:

A few comments / questions:

1. I'm not a regular contributor to LLVM, so please wait for somebody else (like @craig.topper, @RKSimon, or @spatel) to sign off on this.
2. Once one has "add carry", one immediately wants "sub carry/borrow". Please consider adding tests to subcarry.ll.

Add comments more descriptive test names

Oh sh*i, this is the same thing I'm doing in https://reviews.llvm.org/D70012.

Another round of changes.

Update unit tests.

Hi again,

I did a small update.

Update with some intermidiate changes.

In D56214#1344055, @lebedev.ri wrote:

Also, i don't think this should be hardcoded to some particular bitwidth.