Changes

Summary

  1. [DFSan][NFC] Refactor Origin Address Alignment code. (details)
  2. [IR] convert warn-stack-size from module flag to fn attr (details)
  3. Clarify the "env" launch configuration setting. (details)
  4. [mlir][tosa] Enable tosa.div for TosaMakeBroadcastable (details)
  5. [ScalarEvolution] Ensure backedge-taken counts are not pointers. (details)
  6. [NFC] Add getUnderlyingObjects test (details)
  7. Rename MachineMemOperand::getOrdering -> getSuccessOrdering. (details)
Commit 759e7977679299296a0074bc3aba693d3386eb1c by browneee
[DFSan][NFC] Refactor Origin Address Alignment code.

Reviewed By: stephan.yichao.zhao

Differential Revision: https://reviews.llvm.org/D104565
The file was modifiedcompiler-rt/lib/dfsan/dfsan.cpp
Commit 8ace12130526f450c822ca232d1f865b247d7434 by ndesaulniers
[IR] convert warn-stack-size from module flag to fn attr

Otherwise, this causes issues when building with LTO for object files
that use different values.

Link: https://github.com/ClangBuiltLinux/linux/issues/1395

Reviewed By: dblaikie, MaskRay

Differential Revision: https://reviews.llvm.org/D104342
The file was modifiedllvm/docs/LangRef.rst
The file was modifiedllvm/include/llvm/IR/Module.h
The file was modifiedllvm/test/CodeGen/X86/warn-stack.ll
The file was addedclang/test/Frontend/fwarn-stack-size.c
The file was modifiedllvm/lib/IR/Module.cpp
The file was modifiedllvm/test/CodeGen/ARM/warn-stack.ll
The file was modifiedclang/lib/CodeGen/CodeGenModule.cpp
The file was modifiedllvm/lib/CodeGen/PrologEpilogInserter.cpp
The file was addedllvm/test/Verifier/invalid-warn-stack-size.ll
The file was modifiedclang/lib/CodeGen/CodeGenFunction.cpp
The file was modifiedllvm/lib/IR/Verifier.cpp
The file was removedllvm/test/Linker/warn-stack-frame.ll
Commit 4181bfe6888fdc6f24dc42d4ebb295920826de2b by gclayton
Clarify the "env" launch configuration setting.

A few users recently were trying to set environment values when using lldb-vscode and were unsure of the format of the "env" launch configuration setting. Clarify the exact format as when users add the "env" launch config setting, they can see this help string in the IDE.

Differential Revision: https://reviews.llvm.org/D104578
The file was modifiedlldb/tools/lldb-vscode/package.json
Commit ad1a9d629b759f43c8c1ea5d4c710c5c5b4b1e6b by rob.suderman
[mlir][tosa] Enable tosa.div for TosaMakeBroadcastable

TosaMakeBroadcastable needs to include tosa.div, which was added later in the
specification.

Reviewed By: sjarus, NatashaKnk

Differential Revision: https://reviews.llvm.org/D104157
The file was modifiedmlir/lib/Dialect/Tosa/Transforms/TosaMakeBroadcastable.cpp
Commit 8f3d16905d75b07a933d01dc29677fe5867c1b3e by efriedma
[ScalarEvolution] Ensure backedge-taken counts are not pointers.

A backedge-taken count doesn't refer to memory; returning a pointer type
is nonsense. So make sure we always return an integer.

The obvious way to do this would be to just convert the operands of the
icmp to integers, but that doesn't quite work out at the moment:
isLoopEntryGuardedByCond currently gets confused by ptrtoint operations.
So we perform the ptrtoint conversion late for lt/gt operations.

The test changes are mostly innocuous. The most interesting changes are
more complex SCEV expressions of the form "(-1 * (ptrtoint i8* %ptr to
i64)) + %ptr)". This is expected: we can't fold this to zero because we
need to preserve the pointer base.

The call to isLoopEntryGuardedByCond in howFarToZero is less precise
because of ptrtoint operations; this shows up in the function
pr46786_c26_char in ptrtoint.ll. Fixing it here would require more
complex refactoring.  It should eventually be fixed by future
improvements to isImpliedCond.

See https://bugs.llvm.org/show_bug.cgi?id=46786 for context.

Differential Revision: https://reviews.llvm.org/D103656
The file was modifiedllvm/lib/Analysis/ScalarEvolution.cpp
The file was modifiedllvm/test/Transforms/LoopReroll/ptrindvar.ll
The file was modifiedllvm/test/Transforms/LoopIdiom/memset-debugify-remarks.ll
The file was modifiedllvm/test/Transforms/PhaseOrdering/scev-custom-dl.ll
The file was modifiedllvm/test/Transforms/IndVarSimplify/eliminate-exit-no-dl.ll
The file was modifiedllvm/test/Analysis/ScalarEvolution/max-backedge-taken-count-guard-info.ll
The file was modifiedllvm/test/Transforms/LoopVectorize/X86/cost-model-assert.ll
The file was modifiedllvm/test/Transforms/LoopVectorize/pr45259.ll
The file was modifiedllvm/test/Transforms/LoopVectorize/pointer-induction.ll
The file was modifiedllvm/test/Transforms/IndVarSimplify/2011-11-01-lftrptr.ll
The file was modifiedllvm/test/Analysis/ScalarEvolution/no-wrap-symbolic-becount.ll
The file was modifiedllvm/test/Analysis/ScalarEvolution/ptrtoint.ll
The file was modifiedllvm/test/Analysis/ScalarEvolution/nsw.ll
Commit ac15a128d8756074b150bb5cb11bfd93a1a5c30c by Vitaly Buka
[NFC] Add getUnderlyingObjects test

Reviewed By: lebedev.ri

Differential Revision: https://reviews.llvm.org/D104585
The file was modifiedllvm/test/Analysis/LoopAccessAnalysis/underlying-objects-2.ll
Commit 74909e4b6e9bc0da6c197cf6c4419991a8dc335f by efriedma
Rename MachineMemOperand::getOrdering -> getSuccessOrdering.

Since this method can apply to cmpxchg operations, make sure it's clear
what value we're actually retrieving.  This will help ensure we don't
accidentally ignore the failure ordering of cmpxchg in the future.

We could potentially introduce a getOrdering() method on AtomicSDNode
that asserts the operation isn't cmpxchg, but not sure that's
worthwhile.

Differential Revision: https://reviews.llvm.org/D103338
The file was modifiedllvm/lib/Target/NVPTX/NVPTXISelDAGToDAG.cpp
The file was modifiedllvm/lib/CodeGen/GlobalISel/LegalizerInfo.cpp
The file was modifiedllvm/lib/Target/Sparc/SparcISelLowering.cpp
The file was modifiedllvm/lib/Target/Hexagon/HexagonISelLowering.cpp
The file was modifiedllvm/lib/Target/AMDGPU/SIMemoryLegalizer.cpp
The file was modifiedllvm/include/llvm/CodeGen/MachineMemOperand.h
The file was modifiedllvm/lib/Target/Hexagon/HexagonFrameLowering.cpp
The file was modifiedllvm/lib/Target/X86/X86ISelLowering.cpp
The file was modifiedllvm/lib/CodeGen/MachineOperand.cpp
The file was modifiedllvm/lib/Target/SystemZ/SystemZISelLowering.cpp
The file was modifiedllvm/include/llvm/CodeGen/SelectionDAGNodes.h
The file was modifiedllvm/lib/CodeGen/GlobalISel/CombinerHelper.cpp
The file was modifiedllvm/lib/CodeGen/GlobalISel/LegalizerHelper.cpp
The file was modifiedllvm/lib/Target/XCore/XCoreISelLowering.cpp
The file was modifiedllvm/lib/CodeGen/MIRVRegNamerUtils.cpp
The file was modifiedllvm/lib/Target/AArch64/AArch64ISelDAGToDAG.cpp
The file was modifiedllvm/lib/Target/ARM/ARMInstrInfo.td
The file was modifiedllvm/lib/CodeGen/MachineFunction.cpp
The file was modifiedllvm/lib/CodeGen/MachineStableHash.cpp
The file was modifiedllvm/lib/Target/ARM/ARMISelLowering.cpp
The file was modifiedllvm/lib/Target/AArch64/GISel/AArch64InstructionSelector.cpp

Summary

  1. Fix SpecCPU2017's dependency from timeit-target to build-timeit-target (details)
Commit 3e88eaf3f0f1f65cf8df4aef2df5ff47cb10e7c8 by aqjune
Fix SpecCPU2017's dependency from timeit-target to build-timeit-target

Building SpecCPU2017 using cmake raises this error:

```
CMake Error at External/SPEC/SpecCPU2017.cmake:263 (add_dependencies):
  The dependency target "timeit-target" of target "imagevalidate_525-target"
  does not exist.
Call Stack (most recent call first):
  External/SPEC/CINT2017rate/525.x264_r/CMakeLists.txt:24 (speccpu2017_validate_image)
```

I think `timeit-target` should be `build-timeit-target` instead because cmake's progress output has this line:

```
[  3%] Built target build-timeit-target
```

Fixing this resolves the dependency error.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D100734
The file was modifiedExternal/SPEC/SpecCPU2017.cmake (diff)