Format patch

I'm not sure I understand the concern but my impression is that we're debating the difference between the following two equivalent forms of the loop

LGTM for llvm-exegesis.

First comments: statically sized operations.

In D127842#3587277, @lhames wrote:

@courbet Are you the right person to talk to about the llvm-exegesis tool? Can it be moved over to ORC/JITLink?

In D127766#3587383, @msebor wrote:

In D56593#3585621, @goldstein.w.n wrote:

In D56593#3584237, @courbet wrote:

In D56593#3582442, @xbolva00 wrote:

@courbet Any followup as we have got "'__memcmpeq" ?

I was under the impression that bcmp was redirecting to __memcmpeq when the latter was available. Isn't that sufficient ?

It is not.

This was rejected for the same reasons the bcmp optimizations where rejected. bcmp is not standardized and since
glibc has been maintaining it as a true memcmp (that can be used for sort), there is not reason for users to not have
begun to rely on that behavior.

In D56593#3582442, @xbolva00 wrote:

@courbet Any followup as we have got "'__memcmpeq" ?

In general I think this makes a lot more sense.

In D124092#3550117, @dmgreen wrote:

I'm not sure I understand. Why do you think that MaxBytesForAlignment isn't a per-basic-block parameter? Any aligned block can have a MaxBytesForAlignment, and they could all be different from one block to the next, just as alignments can change.

As a very high level, design comment, I would like to note that I think we should strive to get into a state where the lowering of a SizedOp is done via a instrinsic call for all operation type (right now, this is only the case for memcpy).

Update llc tests too.

Rebase on base test.

Address review comments.

Thanks.

Try to get rid of "dependent and not a pointer" checks checks.

In D114988#3172161, @nlopes wrote:

ping

Yes, I think the new approach is what we want. The comments also make it much clearer.

address comment

Add more comments on the approach.

Rebase on submitted unit tests so that we can see the changes better.

add container exclusion tests for operators.

Canonicalize more types and add more container tests.

rebase

Thanks for the details, this explains the motivation well. I think the key point is the combination of:

ping

one more spaceship operator fix.

Is this change observable in some way?

Implement the proposed changes.

In D112453#3103515, @rsmith wrote:

I think this change is being made in an imperfect place, though. Instead of putting a special case in here, how would we feel about making Type::isOverloadableType() smarter, to return false for dependent types that can't possibly be class or enum types (eg, dependent pointer types, array types, and maybe more exotic things like function types, atomic types, and complex types)? This would then apply to all operators, not only unary *. Eg, we know the type of &p where p is T*, and we know the type of p + n where p is T* and n is integral. That change might have a lot more fallout, but it'd certainly be interesting to see what it breaks.