LGTM

Updated tables to more reasonable values.

LGTM

LGTM

I"m working on scrubbing the tables and will post a new version when that is done.

Rebase and fix a bug.

Is this something we can handle in combineSetCCEFLAGS?

This feels subject to DAG combine ordering not folding the cmov+setcc before this combine gets a chance to run. Would this be simpler if we just did it at the intrinsic lowering stage?

Ping

LGTM

Remove the vector reduction flag an associated SelectionDAGBuilder code

Add one use check for scalars as well

In D76649#1944257, @spatel wrote:

There's still 1 other use of the flag in DAGCombiner IIUC, but if we can find a way to get rid of that too, that would be great.

In D76525#1942825, @zoecarver wrote:

@craig.topper I'm not sure what should happen. It should probably just use that CPU (although that's not a great solution). Is there a way to detect if an attribute was used to change the target in which case we could error? What do you think should happen?

Rebase now that I fixed most of the tests to avoid the blacklist

Black list instructions that are currently failing tests.

Rebase. I'm going to try to work on the tests or maybe just start blacklisting instructions until we get the tests fixed.

In D76639#1937693, @sconstab wrote:

In D76639#1937680, @craig.topper wrote:

This probably has a hidden side effect on the pass manager construction. Inserting a module pass into the middle of the pipeline effectively introduces a serialization point in the middle of the pipeline. This means all functions have to reach this point in the pipeline before any function can continue. I believe this will cause the Machine IR for all functions to become resident in memory at once. This will substantially increase the memory usage of the compiler.

Isn't this what already happens with the SymbolRewriter?

This probably has a hidden side effect on the pass manager construction. Inserting a module pass into the middle of the pipeline effectively introduces a serialization point in the middle of the pipeline. This means all functions have to reach this point in the pipeline before any function can continue. I believe this will cause the Machine IR for all functions to become resident in memory at once. This will substantially increase the memory usage of the compiler.

In D74918#1937291, @lebedev.ri wrote:

In D74918#1937237, @zoecarver wrote:

@lebedev.ri Where should I put this? Could you maybe point me to another LLVM target API that clang uses that I could base this off? Maybe it should go inside the triple or just be a static function?

I would have guessed TargetLoweringInfo/TargetTransformInfo, but i'm not sure if we can access it here without violating layering.

Rebase

What should the behavior of the builtin be if the calling function has its own target cpu like attribute((target("arch=sandybridge"))) and that CPU has a different size than the CPU that was passed on the command line?

Fix typo in comment.

Simpler version to think about. Just let Constrained intrinsics handle their own flags completely, and skip them in the common FMF handling.

Preserve address space and change size to UnknownSize.

In D76157#1922467, @efriedma wrote:

I wasn't sure if passing just the "base" pointer was correct.

It doesn't really matter what the MachineMemOperand looks like for an operation that doesn't alias anything. :)

In D76157#1922361, @efriedma wrote:

We want to try to create the best MachineMemOperand we can. That means:

1. In general, we can't express the semantics in MachinePointerInfo; the Value has to be a pointer, not a vector of pointers. So we have to create an "empty" MachinePointerInfo. (But we should make sure to note the address-space correctly.)

LGTM

Looks good to me.