Adding testcase for scalar_math_patterns and AVX512_scalar_math_fp_patterns.
Moving setOperationAction(ISD::STRICT_FADD/STRICT_FSUB/STRICT_FDIV/STRICT_FMUL, MVT::v2f64, Legal) into SSE2 judgment statement.

Rebase.
Add option to the tests.

Pengfei has helped me commit the test cases.
I rebase and add the option "-disable-strictnode-mutation" to the test case.

In D68857#1759743, @craig.topper wrote:

Please pre-commit the test modifications with the old codegen and rebase this patch.

Rebase.
STRICT_FP_ROUND has been set as custom so I remove setting it as legal. When entering the custom processing function, if the operand type is legal,the function behaves the same as setOperationAction(ISD:STRICT_FP_ROUND, TYPE, legal)
Modify the test case. Since we do not disable sse, we can pass float-pointer value by register instead of passing by pointer.

In D68857#1756615, @RKSimon wrote:

In D68857#1756222, @LiuChen3 wrote:

In D68857#1755370, @RKSimon wrote:

The new tests and test renames can be done as an NFC commit - then please rebase this patch

Sorry, I am not clear of what you mean. Do you mean I should make a new patch to add these tests? The tests in my current patch is not just renamed, but also doing functional test. I think it's better to keep them together.
And I think make a new patch to rename the tests is reasonable.

I've updated/added the tests in rG5aaca2355ec2 (matching Craig's changes in rG0cc12b8a8310) - the changes were an NFC cleanup and don't require a new patch. Please can you now rebase?

Rebase

In D68857#1755370, @RKSimon wrote:

The new tests and test renames can be done as an NFC commit - then please rebase this patch

Thanks for all of your help.

@uweigand Thank you, now I get clear of the logic there. I add some of your comment to the original comments in the code, I think it may helps us understand this code better. Or we still keep the previous comments?

update comments and fix a bug

update the comments

@uweigand Thanks for your help.

Modify comment

Fix format problem.

Update as comments.

I'm not sure if there's a possibility: some normal float operations of a backend is not Expand,
but they may think expanding strict-float operation can meet their requirements.
Although I haven't found a case yet.

Binding the value of DisableStrictNodeMutation to flag IsStrictFPEnabled, updating as comments.

@uweigand Thanks for your review. I have added information to see if the target supports strict float, so systemZ can disable strictnode mutation as default.

This patch add an variable EnableStrictNode to the TargetLoweringBase to determine whether the target already supports the strict float operation.
Modify the patch @uweigand's suggestion.

I am working on STRICT_FP_TO_SINT/UINT, too. For now, Pengfei and I thought we can set promotion as custom so we can promote the type in x86 without affecting other backend. What do you think?

OK, I 'll make a try.

Modify the name of tests

Modify the name of tests and delete some RUN line in fp80-strict-scalar.ll.

Rebase and change the name of tests in fp-strict-scalar.ll . Add a test file which only process 80-bit long double type, because tests for 80-bit FP is complex to put into fp-strict-scalar.ll without changing the '–check-prefix'.

This patch fix the broken test: CodeGen/ms-inline-asm.c.

I am sorry I updated two wrong versions. The Diff 226862 is right version.

The Diff 226855 has some problems. This one adds testcase to verify if x87 instructions use/def fpcw and fpcw registers.

Add testcase to verify if x87 instructions use/def fpcw and fpcw registers.

In D60748#1681178, @kib wrote:

In fact, can we have an option controlling this ? Does it have anything to do with -malign-data gcc switch ?

We do want to be able to optionally generate code ABI-compatible with modern gcc, per user discretion.