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

Ping ?

I see nothing obviously wrong with this patch. It'd be better if someone with more ARM experience than I do could review it.

I got sidetracked into some other very urgent project during June. I'll do my best to provide that number as soon as I can. I don't expect the gain, as this, to be that great, but who knows ? What I'm after here is to reduce the impact of D33587 on performances.

I have one more comment. It's looking good.

I don't know go that much so I'll give the opportunity to someone that knows better checks this out.

So maybe we should change floating point undefs into NaNs and let everything else unfold ?

1. My best guess is that it is an oversight, but there would be a reason I'm not aware of.
2. Yes because of legalization.
3. The problem i intended to solve was the (fadd constant, undef) where it gets flipped again and again. fsub and fdiv/frem are not commutative ops so that problem doesn't occur with them.

Do it in all cases.

make comment clearer.

@inouehrs That wouldn't be the same as this will bail when no more combine is found.
@davide It's more like 3% as far as I can tell. The sad truth here, looking into it, is that there are a lot of combine that and undo themselves and most of the perf hit come from there. These transform are the very reason why i limited the number of iterations to begin with.

Spelling

Rebase, fix merge conflicts.

Remove setcc change in combineX86ADD .

This is not relevent anymore.

This is not relevent anymore.