LGTM

And the vasrh one (that I missed) in e8d1578131247d089209952476ba9191ad0295be. Hexagon tests should now pass.

Fixed the Hexagon failures in 824b25fc02dc4544adae55e6451d355f4c6d7055.

There are custom implementations of these functions for 64-bit unsigned values, so you should make it uint64_t. There is no connection with the pointer size.

There is no guarantee that size_t will match the size of a pointer either. Why do you want that anyway?

I'm in favor of treating signed saturation as canonical. The issue in delaying detection of such cases to instruction selection is the volatility of the IR: there is no guarantee that the IR will remain in the same form (expected by isel) from one day to the next. For example, some optimization may decide to just promote the operations to the wider type and only do the extension/truncate once, depending on how many saturating operations may be near one another. Handling this variability in isel is just not feasible.

Looks good to me.

The Hexagon part looks ok.

To clarify: clang-8 hangs on HexagonInstrInfo.cpp when compiling current master branch with this patch applied.

This seems to hang when compiling HexagonInstrInfo.cpp.

LGTM.

What is this in preparation of? Why are only these 3 tests affected?

This commit stopped clang++ from finding libc++:

Ping.

Ping.

The problem is that in some contexts the explicit sign- or zero-extension may be deliberate, regardless of how boolean values are represented in wider types. Other than delegating that to the target experts, I don't know how to address that.

The Hexagon part is ok.

This commit seems to be implicated in a cmake-time warning. See http://lists.llvm.org/pipermail/cfe-dev/2019-March/061837.html for more information.

The Hexagon testcase can be fixed---it's probably just a matter of changing the selection pattern for the instruction we're checking.

There can be many changes to the compiled code between the IR combiner and the DAG combiner, so these patterns can certainly appear before DAG combining takes place. Also, we already combine for rotates in the DAG, this patch only makes it more comprehensive.

Rebased on top of the pre-committed testcases.

Oof, I somehow missed the comments... :o

The Hexagon changes look good.

I was actually thinking about handling of target-specific relocations, and applying them to instructions. We used to have a large chunk of auto-generated code that did that. The implementation in lld is much shorter, so it's probably not a big deal if it needs to be repeated.

Since you're rewrite this, is there any potential for sharing code with lld? Relocating instructions should essentially be the same between these two.

Looks ok to me.

Ping.

This patch uses MatchRotate to do the actual matching, so it's only going to look for opportunities to create a rotate. Maybe that function should be replaced with MatchRotateOrFunnelShift in a future patch.