In D131134#3707397, @craig.topper wrote:

What problem are we trying to solve here? CPUID reports AMX as supported even in 32-bit mode. Why can't the user pass it to the compiler?

change the error report

fix lit fail and handle '-march=native'

In D131134#3699742, @craig.topper wrote:

How does this interact with -march=native -m32. Won't that pick up the amx flag from CPUID?

In D131134#3699742, @craig.topper wrote:

How does this interact with -march=native -m32. Won't that pick up the amx flag from CPUID?

In D131049#3695810, @skan wrote:

Remove NFC in the title? I think this patch is used to fix the build error for auto-generating X86 memory folding table.

In D124435#3515541, @jyknight wrote:

I find the option names you have a bit confusing. I'd like to suggest calling them, instead:

caller: Extend a small integer parameter in the caller; callee will assume it has already been extended.
callee : Pass a small integer parameter directly in caller, extend in callee when converting to full-width.
both: Extend a small integer parameter in the caller; callee ALSO extends when converting to full-width.
default: Use the default rule for the target.

I think that gets more to the point of what's going on here, even though it's not exactly the case that "callee" always extends.

Sorry for the late update. I hope you can take the time to continue reviewing, @rjmccall .
I'm not sure if I understand you correctly. Now if the -mextend-small-integers=default is used, compiler will report error.

rebase and address rjmccall's comments

Thanks, @rjmccall . I'm sorry I don't have much time on this patch recently. I will update it later.

Use -mextend-small-integers=<arg> instead of boolean option

In D124435#3474130, @skan wrote:

Should we update the clang/docs/ReleaseNotes.rst for this?

add one missing comment

Address comments

In D124435#3474130, @skan wrote:

Should we update the clang/docs/ReleaseNotes.rst for this?

fix bug

I think you need to add a new ConservativeExtend kind to ABIArgInfo and make X86_64ABIInfo::classifyArgumentType (and classifyReturnType?) use that instead of Extend.

In D122963#3460934, @rjmccall wrote:

If people think that we'll reliably get the right behavior by the frontend adding sext and zext to call sites but not to function arguments, I can walk you through how to make that change in the frontend.

What we can't do in the frontend is just switch to unconditionally not using sext and zext at all on x86_64, because we need to maintain compatibility with old versions of clang. But we can introduce a flag that makes clang generate incompatible code if someone wants to opt in to it for performance.

According to our internal tests, the performance of most of the tests is not affected. The most affected test performance dropped by %0.76. Average performance dropped 0.25%. This matches our expectations

If there is no better solution, I hope this patch merge in. This is a bug that needs to be fixed.

rebase

Address Phoebe's comments: remove 32-bit target check.

Ping? This bug will cause correctness issues, we need to fix it. I think it is possible to fix in the backend in the current situation.
Is there any other better method, @jyknight @lebedev.ri

It seems we all agree we should extend the parameter both in caller and in callee. This is also the behavior of gcc.
For now, the front-end doesn't have an accurate attribute that describes what we're expecting right now and doesn't know whether the function is external linked. By default clang will do the extension only in the caller. This forced us to do some workarounds on the backend.
We also thought about setting these attributes correctly in the IPO, but is there any possibility that IPO won't do in some cases?
D112942 introduces a new parameter attribute NoExt might help us. But this still means that by default, we will do extension in both caller and callee. And only in some optimization cases, we will do extension in caller or callee. Still not the ideal method that lebedev.ri expected.
Besides, I think that as an ABI issue, the correctness should be guaranteed first, optimization is not always guaranteed.
@lebedev.ri, is there any better approach to fix this issue?

In D122963#3435619, @lebedev.ri wrote:

Still not okay with it. The fix is to fix whatever is emitting the attribute, not completely ignore it.

Address Shenchen's comment

Address Yuanke's comments: do the extension only if the function isn't local linked.

Thanks for you review.

Can you take a review again and +1 if no problem? I missed changing some testcases. Thanks.

Fix check-all fail.

Thanks for you review. The order of operand is changed in final commit: The addend of FMA builtin is moved from the first to the third.

Address comments.

1. Remove redundant option checkRemove redundant option check.
2. Reformat.

Distinguish 0.0 and -0.0 in FMA.

Adress comments

Adress comments.

Adress comments.

Address comments

Thanks for reviewing this patch!

Address pengfei's comments.