In D157458#4646407, @arsenm wrote:

Post-selection code should not be tolerant of registers without a class. It is unequivocally a bug for a used register to pass selection without a class dead or not

Do you think we still need to modify X86FastPreTileConfig?

Thanks for the clarifications @Carrot

I've added a part about alive registers.

Long term I assume we should just have MIR patterns working for ISel, but as long as we rely on DAG patterns I believe this is a good change (we inevitably need to make some tradeoffs in this case anyway), can we land it or are there still some objections?

The peephole optimizer changes look good to me.
+1 on every comments touching on test cases and comments.

Good catch!

BTW, LGTM :D.

Nice clean-up!

Good catch!

The code is reasonable to me, but I am worried by the asserts not being true in general.
I think we should indeed remove SUBREG_TO_REG in the long run and maybe short term, let's turn the asserts into fatal_errors.
That way if this breaks in the wild we'll get reports of the related errors instead of miscompiles.

Yay!

Does this look good to you?

• Use ArithFastMathInterface instead of iterating through the attributes

I'm not super familiar with this code, but that sounds reasonable to me.

• Use the fastmath flags attached to arith op when using getIdentityElement
• Add tests catching that behavior

• Rebase
• Set default value for getIdentity
• Use markdown instead of \p.

In D156345#4542646, @arsenm wrote:

In D156345#4542127, @qcolombet wrote:

Hi @arsenm ,

A maybe more robust temporary fix may be to apply the terminal rule (applyTerminalRule) only on isCopy instructions (right now it is on isCopyLike).

I could be wrong, but I wouldn't be surprised if this is the entry point of the problematic coalesced SUBREG_TO_REGs. And clearly without your fixes, the terminal rule is incorrect on SUBREG_TO_REG.

"UseTerminalRule" is false by default. Swapping the isCopyLike in copyCoalesceInMBB for isCopy induces about 850 test failures

Thanks for the link @rengolin !

A maybe more robust temporary fix may be to apply the terminal rule (applyTerminalRule) only on isCopy instructions (right now it is on isCopyLike).

In my mind, if we have implicit defs on a copy, then we should probably not consider the related instruction as a copy to begin with.

LGTM

This does not yet fix the regression. The isCopyInstr handling needs to start handling implicit-defs on any instruction.

The same problem likely exists everywhere trying to do anything with SUBREG_TO_REG. I don't understand how this managed to be broken for so long.

• Fix Smallest/Largest for maxf/minf respectively.

Does the patch work for you with the additional context?
The TL;DR is the semantic is correct but more recent drivers may not need that optimization anymore.

Partial review

LGTM.

In D154507#4509642, @qcolombet wrote:

Hi @jdoerfert,

In D154507#4487631, @jdoerfert wrote:

In D154507#4487519, @mehdi_amini wrote:

I'm a bit confused @jdoerfert : are there two different uses of the word "demoted" here? Seems like you're referring to a transformation that turns a global into an alloca, whereas here is it just about "demoting" the linkage type of the global?

I do not see the linkage being changed, if so, to what? Local (=private or internal) is already as "good" as it gets.

Given the test result, and the comment ("Find out if a global variable can be demoted to local scope."), it looks to me as if the scope is changed, thus where the variable is "declared/visible".
That said, I was expecting (w/o knowing for sure), that a variable scoped in a function cannot be accessed by other functions. If that is wrong, the first part of my comment is mood.

I think a variable scoped in a function can be accessed by other functions. Meaning, the symbol may not be visible, but the address pointed by this symbol can be accessed (i.e., it is okay to escape), because the allocations are handled at a higher level (the driver).
@guraypp do you have more details on this?

In D154507#4487631, @jdoerfert wrote:

In D154507#4487519, @mehdi_amini wrote:

I'm a bit confused @jdoerfert : are there two different uses of the word "demoted" here? Seems like you're referring to a transformation that turns a global into an alloca, whereas here is it just about "demoting" the linkage type of the global?

I do not see the linkage being changed, if so, to what? Local (=private or internal) is already as "good" as it gets.

Given the test result, and the comment ("Find out if a global variable can be demoted to local scope."), it looks to me as if the scope is changed, thus where the variable is "declared/visible".
That said, I was expecting (w/o knowing for sure), that a variable scoped in a function cannot be accessed by other functions. If that is wrong, the first part of my comment is mood.

I've sent a patch for review to fix the NVPTX backend limitation https://reviews.llvm.org/D154507

• Use cast free implementation

• Make the AggregatedOpInterface specific to Linalg for now (we may want to drop the interface and just use rewriter patterns.)
• Fix nits: comments, function names, move the builder first in all the added functions
• Make the implementation of the transform op cleaner (i.e., support multi result in the returned value).

In D154074#4471755, @Dinistro wrote:

In D154074#4471645, @qcolombet wrote:

Talked with @guraypp offline. I think this is a limitation in the PTX backend.

Is it possible to fix this in the PTX backend then? A limitation in this backend should not be the reason to extend the symbol visibility that potentially affects all of MLIR.

Talked with @guraypp offline. I think this is a limitation in the PTX backend.

Thanks for the added descriptions. Still LGTM :).

LGTM with nits on the descriptions to make things easier to understand.

• Add a tile and fuse test
• Remove deprecated use of cast
• Fix the way we generate the dimension (value vs. attribute)

LGTM with nits.