Ping ?

Absolutely.

Ping ?

Revert changes in LanaiAluCode.h

The change in LanaiAluCode.h are indeed unrelated, let me remove them.

LGTM.

Add a mention of the change in the release notes.

That being said, you are correct, I should mention this in the release note and warn on the ML.

There are numerous problem with ADDC/ADDE and the sub equivalent, specifically because they are glues :) In addition, it doesn't really simplify much because there is still UADDO and friend to support, regardless.

Use isBitwiseNot
Merge flipBooleanConstant into flipBoolean
Add more specific test cases.

Add bugfix for Hexagon and rebase

Add a comment to explain the check for MVT::i16 .

@niravd I added a test case in rL323868 . The problem was by trying to extract the lower 32 bits of a 16 bit register, which is obviously not possible.

Reduce the diff to simply avoid doing the high register trick.
It turns out that there is a bug in the other optimization made in the orginal diff, so it seems like a better idea to split that out in several smaller steps to ensure progress.

Ok sounds like this isn't the right approach, closing this one.

Remove leftover DEBUG

Remove TEST8ri_NOREX
Merge codepath for testl and testw

@niravd It is rebased on top of D42615 . Alternatively, it can be rebased on top of D42646 with identical results as, as per discussion with @craig.topper , the test instruction has higher throughput than bt so maybe that's a preferable solution. Either way, the high register trick problem has been identified and there are several possible solutions.

On a second look, when disabling this trick, I only get improvement in various test cases. I'm not sure what's the impact in real source code is, but I'm not convinced this trick is worth doing at all at this stage.

Looks like this end up being a problem when the value is in EDI due to calling convention. So a few question come to mind:
1/ Shouldn't this optimization be done only after register allocation, if the selected register allows for it ? This would cause it to fail once in a while because the register allocator do not chose the proper register, but it's probably preferable to the extra copies.
2/ Is that possible to hint the register allocator that something is desirable ? For instance, that we would like this value to be in a GR8_NOREX register, but if that's not the case, don't create a copy for it ?

@niravd After proposing D42615 , it seems like using test instead of bt is the right thing to do as it has higher throughput - unless more work is required to materialize the constant. There is a bug in the materialization of test that cause it to sometime create needless copy. This needs to be fixed, regardless of what this diff does. I think we should proceed with this one.

@craig.topper I had no idea bt has lower throughput than test, I assumed it was the same. If that's the case, then this approach doesn't make much sense.

Rebase on top of D42615, which ensure there are no more regression for pattern involving test/bt.

Congrats !

Make sure we do not transform is x can be Nan, also do the transformation for fsub and add arguments in various tests to make sure they don't get folded and continue to test what they are supposed to.

Not relevant anymore.

This is not relevent anymore.

@RKSimon I'll find a way to make that fast, or find an alternative like activating it only in some specific situations. In addition to solving my specific problem, it seems to improve numerous other things, especially for the AMD backend. In any case, I think D33840 is a good thing either way and we should proceed with it.

rebase

OK, benchmarks. Compiling clang from a bc containing clang in its entierety. With the patch:

Add comments