bcm5719-llvm/llvm/test/CodeGen/SystemZ, branch meklort-10.0.1

[SystemZ] Bugfix in emitSelect()

2020-02-12T09:50:02+00:00

When more than one SelectPseudo instruction is handled a new MBB is returned. This must not be done if that would result in leaving an undhandled isel pseudo behind in the original MBB. Fixes https://bugs.llvm.org/show_bug.cgi?id=44849. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D74352 (cherry picked from commit 0311e28e9cc01a244faa774b8cab337b45404fa9)

[FPEnv] Fix chain handling regression after 04a8696

2020-01-14T13:10:57+00:00

Code in getRoot made the assumption that every node in PendingLoads must always itself have a dependency on the current DAG root node. After the changes in 04a8696, it turns out that this assumption no longer holds true, causing wrong codegen in some cases (e.g. stores after constrained FP intrinsics might get deleted). To fix this, we now need to make sure that the TokenFactor created by getRoot always includes the previous root, if there is no implicit dependency already present. The original getControlRoot code already has exactly this check, so this patch simply reuses that code now for getRoot as well. This fixes the regression. NFC if no constrained FP intrinsic is present.

[FPEnv] Fix chain handling for fpexcept.strict nodes

2020-01-13T13:38:49+00:00

We need to ensure that fpexcept.strict nodes are not optimized away even if the result is unused. To do that, we need to chain them into the block's terminator nodes, like already done for PendingExcepts. This patch adds two new lists of pending chains, PendingConstrainedFP and PendingConstrainedFPStrict to hold constrained FP intrinsic nodes without and with fpexcept.strict markers. This allows not only to solve the above problem, but also to relax chains a bit further by no longer flushing all FP nodes before a store or other memory access. (They are still flushed before nodes with other side effects.) Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D72341

[SystemZ] Fix matching another pattern for nxgrk (PR44496)

2020-01-09T18:06:22+00:00

SystemZDAGToDAGISel::Select will attempt to split logical instruction with a large immediate constant. This must not happen if the result matches one of the z15 combined operations, so the code checks for those. However, one of them was missed, causing invalid code to be generated in the test case for PR44496.

[SystemZ] Extend fp-strict-alias test case

2020-01-07T11:44:51+00:00

Explicitly add test for fpexcept.maytrap intrinsics.

[SystemZ] Fix python failure in test case

2020-01-07T09:26:37+00:00

With recent Python the Large/spill-02.py test failed with an error: TypeError: can't multiply sequence by non-int of type 'float'

[SystemZ] Create brcl 0,0 instead of brcl 0,3 in EmitNop for 6 bytes.

2020-01-02T21:21:04+00:00

For consistency with GCC, the target label is moved to the brcl itself instead of the next instruction. Review: Ulrich Weigand

Migrate function attribute "no-frame-pointer-elim"="false" to "frame-pointer"="none" as cleanups after D56351

2019-12-25T00:27:51+00:00

Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" as cleanups after D56351

2019-12-24T23:57:33+00:00

[FPEnv][X86] More strict int <-> FP conversion fixes

2019-12-23T20:11:45+00:00

Fix several several additional problems with the int <-> FP conversion logic both in common code and in the X86 target. In particular: - The STRICT_FP_TO_UINT expansion emits a floating-point compare. This compare can raise exceptions and therefore needs to be a strict compare. I've made it signaling (even though quiet would also be correct) as signaling is the more usual default for an LT. This code exists both in common code and in the X86 target. - The STRICT_UINT_TO_FP expansion algorithm was incorrect for strict mode: it emitted two STRICT_SINT_TO_FP nodes and then used a select to choose one of the results. This can cause spurious exceptions by the STRICT_SINT_TO_FP that ends up not chosen. I've fixed the algorithm to use only a single STRICT_SINT_TO_FP instead. - The !isStrictFPEnabled logic in DoInstructionSelection would sometimes do the wrong thing because it calls getOperationAction using the result VT. But for some opcodes, incuding [SU]INT_TO_FP, getOperationAction needs to be called using the operand VT. - Remove some (obsolete) code in X86DAGToDAGISel::Select that would mutate STRICT_FP_TO_[SU]INT to non-strict versions unnecessarily. Reviewed by: craig.topper Differential Revision: https://reviews.llvm.org/D71840