SuccessChanges

Summary

  1. AMDGPU: Have a few selection failure tests check both paths (details)
  2. [X86] Copy the tuning features and scheduler model from pentium4/x86-64 to generic (details)
  3. [PowerPC] Do not use FISel for calls and TOC-based accesses with PC-Rel (details)
  4. AMDGPU/GlobalISel: Handle AGPRs used for SGPR operands. (details)
  5. [lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID (details)
  6. [x86][AArch64] adjust fast-math-flags in tests; NFC (details)
  7. [DAGCombine]: Fold X/Sqrt(X) to Sqrt(X) (details)
  8. [LLDB] Fix how ValueObjectVariable handles DW_AT_const_value when the DWARFExpression holds the data that represents a constant value (details)
Commit 05a3c8848a08fea5b832e69b94d3d647ef29f745 by Matthew.Arsenault
AMDGPU: Have a few selection failure tests check both paths

SelectionDAG and GlobalISel take different failure paths for these and
end up producing different failure errors. Check both so the test
passes when the default is switched.
The file was modifiedllvm/test/CodeGen/AMDGPU/div_i128.ll (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/llvm.amdgcn.ds.gws.sema.release.all.ll (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/unsupported-image-a16.ll (diff)
The file was modifiedllvm/test/CodeGen/AMDGPU/unsupported-image-g16.ll (diff)
Commit f7c87b7e376773c555d92d02d8a52a811caf2fbc by craig.topper
[X86] Copy the tuning features and scheduler model from pentium4/x86-64 to generic

This is preparation for making clang default to -mtune=generic when no -march is specified. This will allow the default tuning to be "generic" even though our default march is "pentium4" or "x86-64".

To avoid llc lit test regressions, if no mcpu is specified, I've defaulted tune to use i586 to match the old tuning settings of no CPU. Some tests explicitly used -mcpu=generic which I've removed so they instead get this default of architecture features from generic and tune from i586.

I updated one llvm-mca test to check a different CPU since generic has a scheduler model now

Differential Revision: https://reviews.llvm.org/D86312
The file was modifiedllvm/lib/Target/X86/X86Subtarget.cpp (diff)
The file was modifiedllvm/test/CodeGen/X86/full-lsr.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/masked-iv-safe.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/2007-11-06-InstrSched.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/vec_call.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/widen_cast-1.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/optimize-max-3.ll (diff)
The file was modifiedllvm/lib/Target/X86/X86.td (diff)
The file was modifiedllvm/test/tools/llvm-mca/X86/no-sched-model.s (diff)
The file was modifiedllvm/test/CodeGen/X86/add.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/select.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/abi-isel.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/lsr-static-addr.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/lsr-loop-exit-cond.ll (diff)
The file was modifiedllvm/test/CodeGen/X86/vec_setcc-2.ll (diff)
Commit 075a92dea11ece9e7b7e24238fa995a42b2128d0 by nemanja.i.ibm
[PowerPC] Do not use FISel for calls and TOC-based accesses with PC-Rel

PC-Relative addressing introduces a fair bit of complexity for correctly
eliminating TOC accesses. FastISel does not include any of that handling so we
miscompile code with -mcpu=pwr10 -O0 if it includes an external call that
FastISel does not handle followed by any of the following:

    Floating point constant materialization
    Materialization of a GlobalValue
    Call that FastISel does handle

This patch switches to SDISel for any of the above.

Differential revision: https://reviews.llvm.org/D86343
The file was modifiedllvm/test/CodeGen/PowerPC/fast-isel-pcrel.ll (diff)
The file was modifiedllvm/lib/Target/PowerPC/PPCFastISel.cpp (diff)
Commit 77e5a195f818b9ace91f7b12ab948b21d7918238 by Matthew.Arsenault
AMDGPU/GlobalISel: Handle AGPRs used for SGPR operands.

We would still need to waterfall if the value were somehow an AGPR,
and also need to explicitly copy to a VGPR.
The file was modifiedllvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp (diff)
The file was addedllvm/test/CodeGen/AMDGPU/GlobalISel/regbankselect-waterfall-agpr.mir
The file was modifiedllvm/test/CodeGen/AMDGPU/GlobalISel/regbankselect-amdgcn.readlane.mir (diff)
Commit a842950b62b6d029a392c3c312c6495d6368c2a4 by Jonas Devlieghere
[lldb] Add a SymbolFileProvider to record and replay calls to dsymForUUID

When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.

Differential revision: https://reviews.llvm.org/D86389
The file was modifiedlldb/source/Commands/CommandObjectReproducer.cpp (diff)
The file was addedlldb/test/Shell/Reproducer/Inputs/dsymforuuid.sh
The file was modifiedlldb/include/lldb/Utility/ReproducerProvider.h (diff)
The file was modifiedlldb/source/Symbol/LocateSymbolFile.cpp (diff)
The file was addedlldb/test/Shell/Reproducer/TestDebugSymbols.test
The file was addedlldb/test/Shell/Reproducer/Inputs/core
The file was modifiedlldb/include/lldb/Utility/Reproducer.h (diff)
The file was modifiedlldb/source/Utility/ReproducerProvider.cpp (diff)
The file was modifiedlldb/source/Symbol/LocateSymbolFileMacOSX.cpp (diff)
Commit a74dc598fb6b878908ffe769025f79f17e54cab0 by spatel
[x86][AArch64] adjust fast-math-flags in tests; NFC

This goes with the proposal in D86403.
The file was modifiedllvm/test/CodeGen/X86/sqrt-fastmath.ll (diff)
The file was modifiedllvm/test/CodeGen/AArch64/sqrt-fastmath.ll (diff)
Commit 62e91bf563337fff93be0059ecb1f4dae32d8980 by spatel
[DAGCombine]: Fold X/Sqrt(X) to Sqrt(X)

With FMF ( "nsz" and " reassoc") fold X/Sqrt(X) to Sqrt(X).

This is done after targets have the chance to produce a
reciprocal sqrt estimate sequence because that expansion
is probably more efficient than an expansion of a
non-reciprocal sqrt. That is also why we deferred doing
this transform in IR (D85709).

Differential Revision: https://reviews.llvm.org/D86403
The file was modifiedllvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (diff)
The file was modifiedllvm/test/CodeGen/X86/sqrt-fastmath.ll (diff)
The file was modifiedllvm/test/CodeGen/AArch64/sqrt-fastmath.ll (diff)
Commit 93b255142bb7025f62cf83dd5b7d3b04aab5445b by shafik
[LLDB] Fix how ValueObjectVariable handles DW_AT_const_value when the DWARFExpression holds the data that represents a constant value

In some cases when we have a DW_AT_const_value and the data can be found in the
DWARFExpression then ValueObjectVariable does not handle it properly and we end
up with an extracting data from value failed error.

The test is a very stripped down assembly file since reproducing this relies on the results of compiling with -O1 which may not be stable over time.

Differential Revision: https://reviews.llvm.org/D86311
The file was modifiedlldb/source/Core/ValueObjectVariable.cpp (diff)
The file was addedlldb/test/Shell/SymbolFile/DWARF/DW_AT_const_value.s