And then, after said minimal amount of effort, it turns out that the patch actually hurts performance on some AMD CPUs, and people bring out pitchforks for Intel intentionally slowing down AMD?

It seems to me that the current approach is the most conservative: limit the impact to what you know best. Leave it to the experts of the other system to do whatever is needed.

I don't understand your scenario. The minimal amount of effort includes a benchmark, so it wouldn't be enabled if it hurt performance.

How many AMD CPU configurations exist? Does a minimal effort require regression testing all of them? On how many benchmarks? How do you know that there aren’t untested potholes in AMD CPUs that you may not be aware of?

In the end, the result of this feature is a performance improvement for some and status quo (no perf regression) for everybody else. It’s a net benefit with no downside in absolute terms.

In addition, it provides a free roadmap for AMD or its users on how to get the same benefit as well.

The potential backlash of enabling this for AMD as well by somebody of Intel (“active sabotage!!!”) is much larger than this tempest in a teacup where AMD is currently missing out on something.

The same benchmarks you used to justify adding it in the first place, on their current model and ideally a slightly older one, would be sufficient.

> The potential backlash of enabling this for AMD as well by somebody of Intel (“active sabotage!!!”) is much larger than this tempest in a teacup where AMD is currently missing out on something.

I disagree.

Historically Intel has been found to create suboptimal code paths in its own compiler, in addition to not enabling features supported on competitor's platform, in its own compiler.

What happens if the implementation is slower but still works on AMD? Is Intel responsible for also performance testing and determining if/when to disable an implementation on a given chip? You're putting a lot of burden on Intel to do extensive testing and also not protecting them from criticism if a change is suboptimal for a competitor.

I think it's fine to submit a patch that's known to be good for a subset of CPUs and perhaps it should be tagged for another maintainer (e.g. AMD) to review and contribute to as well.

If the original patch contained a benchmark showing that it was slower on the current AMD processors then this would be a reasonable argument.

It did not, because no such testing was done.

I think there's a pretty low baseline of effort they can put in. I also think that if they enabled new code paths for newer instructions that turned out to be slower on AMD, very few people would claim this was Intel being evil. Most would blame AMD for selling a defective product.

I would argue it's absurd ask for Intel to maintain test platforms for a competitor.

At best you could ask them to flag platform specific code in such a way that others, who are better equipped, can test against other platforms.