FailedChanges

Summary

  1. Attempt to fix buildbot failures with MSVC
  2. [ELF] Only allow the binding of SharedSymbol to change for the first undef ref Fixes PR42442 t.o has a STB_GLOBAL undef ref to f t2.so has a STB_WEAK undef ref to f t1.so defines f ld.lld t.o t1.so t2.so currently sets the binding of `f` to STB_WEAK. This is not correct because there exists a STB_GLOBAL undef ref from a regular object. The problem is that resolveUndefined() doesn't check if the undef ref is seen for the first time: if (isShared() || isLazy() || (isUndefined() && Other.Binding != STB_WEAK)) Binding = Other.Binding; The isShared() condition should be `isShared() && !Referenced` where Referenced is set to true after an undef ref is seen. In practice, when linking a pthread program with glibc: // a.o #include <pthread.h> pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER; int main() { pthread_mutex_unlock(&mu); } {clang,gcc} -fuse-ld=lld a.o -lpthread # libpthread.so is linked before libgcc_s.so.1 The weak undef pthread_mutex_unlock in libgcc_s.so.1 makes the result weak, which diverges from GNU linkers where STB_DEFAULT is used: 23: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock (Note, if -pthread is used instead, libpthread.so will be linked **after** libgcc_s.so.1 . lld sets the binding to the expected STB_GLOBAL) Similar linking sequences (ld.lld t.o t1.so t2.so) appear to be used by Go, which cause a build error https://github.com/golang/go/issues/31912. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D63974
  3. [llvm] [Support] Clean PrintStackTrace() ptr arithmetic up Use '%tu' modifier for pointer arithmetic since we are using C++11 already. Prefer static_cast<> over C-style cast. Remove unnecessary conversion of result, and add const qualifier to converted pointers, to silence the following warning: In file included from /home/mgorny/llvm-project/llvm/lib/Support/Signals.cpp:220:0: /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc: In function ‘void llvm::sys::PrintStackTrace(llvm::raw_ostream&)’: /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc:546:53: warning: cast from type ‘const void*’ to type ‘char*’ casts away qualifiers [-Wcast-qual] (char*)dlinfo.dli_saddr)); ^~~~~~~~~ Differential Revision: https://reviews.llvm.org/D63888
  4. [IDF] Generalize IDFCalculator to be used with Clang's CFG I'm currently working on a GSoC project that aims to improve the the bug reports of the analyzer. The main heuristic I plan to use is to explain values that are a control dependency of the bug location better. 01 bool b = messyComputation(); 02 int i = 0; 03 if (b) // control dependency of the bug site, let's explain why we assume val 04 // to be true 05 10 / i; // warn: division by zero Because of this, I'd like to generalize IDFCalculator so that I could use it for Clang's CFG: D62883. In detail: * Rename IDFCalculator to IDFCalculatorBase, make it take a general CFG node type as a template argument rather then strictly BasicBlock (but preserve ForwardIDFCalculator and ReverseIDFCalculator) * Move IDFCalculatorBase from llvm/include/llvm/Analysis to llvm/include/llvm/Support (but leave the BasicBlock variants in llvm/include/llvm/Analysis) * clang-format the file since this patch messes up git blame anyways * Change typedef to using * Add the new type ChildrenGetterTy, and store an instance of it in IDFCalculatorBase. This is important because I'll have to specialize it for Clang's CFG to filter out nullpointer successors, similarly to D62507. Differential Revision: https://reviews.llvm.org/D63389
  5. [ARM] MVE: allow soft-float ABI to pass vector types. Passing a vector type over the soft-float ABI involves it being split into four GPRs, so the first thing that has to happen at the start of the function is to recombine those into a vector register. The ABI types all vectors as v2f64, so we need to support BUILD_VECTOR for that type, which I do in this patch by allowing it to be expanded in terms of INSERT_VECTOR_ELT, and writing an ISel pattern for that in turn. Similarly, I provide a rule for EXTRACT_VECTOR_ELT so that a returned vector can be marshalled back into GPRs. While I'm here, I've also added ISD::UNDEF to the list of operations we turn back on in `setAllExpand`, because I noticed that otherwise it gets expanded into a BUILD_VECTOR with explicit zero inputs, leading to pointless machine instructions to zero out a vector register that's about to have every lane overwritten of in any case. Reviewers: dmgreen, ostannard Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63937
  6. [ARM] Stop using scalar FP instructions in integer-only MVE mode. If you compile with `-mattr=+mve` (enabling integer MVE instructions but not floating-point ones), then the scalar FP //registers// exist and it's legal to move things in and out of them, load and store them, but it's not legal to do arithmetic on them. In D60708, the calls to `addRegisterClass` in ARMISelLowering that enable use of the scalar FP registers became conditionalised on `Subtarget->hasFPRegs()` instead of `Subtarget->hasVFP2Base()`, so that loads, stores and moves of those registers would work. But I didn't realise that that would also enable all the operations on those types by default. Now, if the target doesn't have basic VFP, we follow up those `addRegisterClass` calls by turning back off all the nontrivial operations you can perform on f32 and f64. That causes several knock-on failures, which are fixed by allowing the `VMOVDcc` and `VMOVScc` instructions to be selected even if all you have is `HasFPRegs`, and adjusting several checks for 'is this a double in a single-precision-only world?' to the more general 'is this any FP type we can't do arithmetic on?'. Between those, the whole of the `float-ops.ll` and `fp16-instructions.ll` tests can now run in MVE-without-FP mode and generate correct-looking code. One odd side effect is that I had to relax the check lines in that test so that they permit test functions like `add_f` to be generated as tailcalls to software FP library functions, instead of ordinary calls. Doing that is entirely legal, but the mystery is why this is the first RUN line that's needed the relaxation: on the usual kind of non-FP target, no tailcalls ever seem to be generated. Going by the llc messages, I think `SoftenFloatResult` must be perturbing the code generation in some way, but that's as much as I can guess. Reviewers: dmgreen, ostannard Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63938
  7. gn build: Merge r364866
  8. [yaml2obj] - An attempt to fix a ppc64be build bot after r364898 I guess the problem is because of endianess of the bytes tested by "od" tool. I changed the Content sequence as it does not actually matter.
  9. [X86] resolveTargetShuffleInputsAndMask - add repeated input handling. We were relying on combineX86ShufflesRecursively to handle this - this patch gets it done earlier which should make it easier for other code to use resolveTargetShuffleInputsAndMask.
  10. [test/Object] - Fix build bot. Fixed mistype in the test case. BB: http://lab.llvm.org:8011/builders/lld-x86_64-ubuntu-fast/builds/2720/steps/test-check-all/logs/stdio
  11. [clang][ArgumentAdjusters] Do not add fsyntax-only if already exists Reviewers: hokein Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64063
  12. [Object/invalid.test] - Convert 3 more sub-tests to YAML This allows to remove 3 more precompiled binaries from the inputs. Differential revision: https://reviews.llvm.org/D63880
  13. [mips] Mark P5600 scheduling model as complete
  14. clang-cl: Make /d1reportAllClassLayout actually work and improve test See review thread for r301567.
  15. [mips] Add missing schedinfo for FPU load/store/conv instructions
  16. [mips] Map SNOP, NOP to the P5600Nop scheduler resource
  17. [yaml2obj] - Allow overriding sh_offset field from the YAML. Some of our test cases are using objects which has sections with a broken sh_offset field. There was no way to set it from YAML until this patch. Differential revision: https://reviews.llvm.org/D63879
  18. [NFC][InstCombine] Revisit tests for "redundant shift input masking" (PR42456)
  19. [DWARF] Simplify dumping of a .debug_addr section. This patch removes the part which tried to interpret addresses in that section as offsets and simplifies the remaining code. Differential Revision: https://reviews.llvm.org/D64020
Revision 364914 by szelethus:
Attempt to fix buildbot failures with MSVC
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm/Analysis/IteratedDominanceFrontier.h (diff)llvm.src/include/llvm/Analysis/IteratedDominanceFrontier.h
Revision 364913 by maskray:
[ELF] Only allow the binding of SharedSymbol to change for the first undef ref

Fixes PR42442

t.o has a STB_GLOBAL undef ref to f
t2.so has a STB_WEAK undef ref to f
t1.so defines f

ld.lld t.o t1.so t2.so currently sets the binding of `f` to STB_WEAK.
This is not correct because there exists a STB_GLOBAL undef ref from a
regular object. The problem is that resolveUndefined() doesn't check
if the undef ref is seen for the first time:

    if (isShared() || isLazy() || (isUndefined() && Other.Binding != STB_WEAK))
      Binding = Other.Binding;

The isShared() condition should be `isShared() && !Referenced`
where Referenced is set to true after an undef ref is seen.

In practice, when linking a pthread program with glibc:

    // a.o
    #include <pthread.h>
    pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER;
    int main() { pthread_mutex_unlock(&mu); }

{clang,gcc} -fuse-ld=lld a.o -lpthread # libpthread.so is linked before libgcc_s.so.1

The weak undef pthread_mutex_unlock in libgcc_s.so.1 makes the result
weak, which diverges from GNU linkers where STB_DEFAULT is used:

    23: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock

(Note, if -pthread is used instead, libpthread.so will be linked **after**
libgcc_s.so.1 . lld sets the binding to the expected STB_GLOBAL)

Similar linking sequences (ld.lld t.o t1.so t2.so) appear to be used by
Go, which cause a build error https://github.com/golang/go/issues/31912.

Reviewed By: grimar, ruiu

Differential Revision: https://reviews.llvm.org/D63974
Change TypePath in RepositoryPath in Workspace
The file was modified/lld/trunk/ELF/Symbols.cpp (diff)lld.src/ELF/Symbols.cpp
The file was modified/lld/trunk/ELF/Symbols.h (diff)lld.src/ELF/Symbols.h
The file was modified/lld/trunk/test/ELF/weak-undef-shared.s (diff)lld.src/test/ELF/weak-undef-shared.s
The file was added/lld/trunk/test/ELF/weak-undef-shared2.slld.src/test/ELF/weak-undef-shared2.s
Revision 364912 by mgorny:
[llvm] [Support] Clean PrintStackTrace() ptr arithmetic up

Use '%tu' modifier for pointer arithmetic since we are using C++11
already.  Prefer static_cast<> over C-style cast.  Remove unnecessary
conversion of result, and add const qualifier to converted pointers,
to silence the following warning:

  In file included from /home/mgorny/llvm-project/llvm/lib/Support/Signals.cpp:220:0:
  /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc: In function ‘void llvm::sys::PrintStackTrace(llvm::raw_ostream&)’:
  /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc:546:53: warning: cast from type ‘const void*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]
                                         (char*)dlinfo.dli_saddr));
                                                       ^~~~~~~~~

Differential Revision: https://reviews.llvm.org/D63888
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Support/Unix/Signals.inc (diff)llvm.src/lib/Support/Unix/Signals.inc
Revision 364911 by szelethus:
[IDF] Generalize IDFCalculator to be used with Clang's CFG

I'm currently working on a GSoC project that aims to improve the the bug reports
of the analyzer. The main heuristic I plan to use is to explain values that are
a control dependency of the bug location better.

01 bool b = messyComputation();
02 int i = 0;
03 if (b) // control dependency of the bug site, let's explain why we assume val
04        // to be true
05   10 / i; // warn: division by zero

Because of this, I'd like to generalize IDFCalculator so that I could use it for
Clang's CFG: D62883.

In detail:

* Rename IDFCalculator to IDFCalculatorBase, make it take a general CFG node
  type as a template argument rather then strictly BasicBlock (but preserve
  ForwardIDFCalculator and ReverseIDFCalculator)
* Move IDFCalculatorBase from llvm/include/llvm/Analysis to
  llvm/include/llvm/Support (but leave the BasicBlock variants in
  llvm/include/llvm/Analysis)
* clang-format the file since this patch messes up git blame anyways
* Change typedef to using
* Add the new type ChildrenGetterTy, and store an instance of it in
  IDFCalculatorBase. This is important because I'll have to specialize it for
  Clang's CFG to filter out nullpointer successors, similarly to D62507.

Differential Revision: https://reviews.llvm.org/D63389
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm/Analysis/IteratedDominanceFrontier.h (diff)llvm.src/include/llvm/Analysis/IteratedDominanceFrontier.h
The file was added/llvm/trunk/include/llvm/Support/GenericIteratedDominanceFrontier.hllvm.src/include/llvm/Support/GenericIteratedDominanceFrontier.h
The file was modified/llvm/trunk/lib/Analysis/CMakeLists.txt (diff)llvm.src/lib/Analysis/CMakeLists.txt
The file was removed/llvm/trunk/lib/Analysis/IteratedDominanceFrontier.cppllvm.src/lib/Analysis/IteratedDominanceFrontier.cpp
Revision 364910 by statham:
[ARM] MVE: allow soft-float ABI to pass vector types.

Passing a vector type over the soft-float ABI involves it being split
into four GPRs, so the first thing that has to happen at the start of
the function is to recombine those into a vector register. The ABI
types all vectors as v2f64, so we need to support BUILD_VECTOR for
that type, which I do in this patch by allowing it to be expanded in
terms of INSERT_VECTOR_ELT, and writing an ISel pattern for that in
turn. Similarly, I provide a rule for EXTRACT_VECTOR_ELT so that a
returned vector can be marshalled back into GPRs.

While I'm here, I've also added ISD::UNDEF to the list of operations
we turn back on in `setAllExpand`, because I noticed that otherwise it
gets expanded into a BUILD_VECTOR with explicit zero inputs, leading
to pointless machine instructions to zero out a vector register that's
about to have every lane overwritten of in any case.

Reviewers: dmgreen, ostannard

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D63937
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp (diff)llvm.src/lib/Target/ARM/ARMISelLowering.cpp
The file was modified/llvm/trunk/lib/Target/ARM/ARMISelLowering.h (diff)llvm.src/lib/Target/ARM/ARMISelLowering.h
The file was modified/llvm/trunk/lib/Target/ARM/ARMInstrMVE.td (diff)llvm.src/lib/Target/ARM/ARMInstrMVE.td
The file was modified/llvm/trunk/test/CodeGen/Thumb2/mve-div-expand.ll (diff)llvm.src/test/CodeGen/Thumb2/mve-div-expand.ll
The file was modified/llvm/trunk/test/CodeGen/Thumb2/mve-fmath.ll (diff)llvm.src/test/CodeGen/Thumb2/mve-fmath.ll
The file was modified/llvm/trunk/test/CodeGen/Thumb2/mve-fp-negabs.ll (diff)llvm.src/test/CodeGen/Thumb2/mve-fp-negabs.ll
The file was modified/llvm/trunk/test/CodeGen/Thumb2/mve-shuffle.ll (diff)llvm.src/test/CodeGen/Thumb2/mve-shuffle.ll
The file was modified/llvm/trunk/test/CodeGen/Thumb2/mve-simple-arith.ll (diff)llvm.src/test/CodeGen/Thumb2/mve-simple-arith.ll
The file was added/llvm/trunk/test/CodeGen/Thumb2/mve-soft-float-abi.llllvm.src/test/CodeGen/Thumb2/mve-soft-float-abi.ll
Revision 364909 by statham:
[ARM] Stop using scalar FP instructions in integer-only MVE mode.

If you compile with `-mattr=+mve` (enabling integer MVE instructions
but not floating-point ones), then the scalar FP //registers// exist
and it's legal to move things in and out of them, load and store them,
but it's not legal to do arithmetic on them.

In D60708, the calls to `addRegisterClass` in ARMISelLowering that
enable use of the scalar FP registers became conditionalised on
`Subtarget->hasFPRegs()` instead of `Subtarget->hasVFP2Base()`, so
that loads, stores and moves of those registers would work. But I
didn't realise that that would also enable all the operations on those
types by default.

Now, if the target doesn't have basic VFP, we follow up those
`addRegisterClass` calls by turning back off all the nontrivial
operations you can perform on f32 and f64. That causes several
knock-on failures, which are fixed by allowing the `VMOVDcc` and
`VMOVScc` instructions to be selected even if all you have is
`HasFPRegs`, and adjusting several checks for 'is this a double in a
single-precision-only world?' to the more general 'is this any FP type
we can't do arithmetic on?'. Between those, the whole of the
`float-ops.ll` and `fp16-instructions.ll` tests can now run in
MVE-without-FP mode and generate correct-looking code.

One odd side effect is that I had to relax the check lines in that
test so that they permit test functions like `add_f` to be generated
as tailcalls to software FP library functions, instead of ordinary
calls. Doing that is entirely legal, but the mystery is why this is
the first RUN line that's needed the relaxation: on the usual kind of
non-FP target, no tailcalls ever seem to be generated. Going by the
llc messages, I think `SoftenFloatResult` must be perturbing the code
generation in some way, but that's as much as I can guess.

Reviewers: dmgreen, ostannard

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D63938
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/ARM/ARMISelLowering.cpp (diff)llvm.src/lib/Target/ARM/ARMISelLowering.cpp
The file was modified/llvm/trunk/lib/Target/ARM/ARMISelLowering.h (diff)llvm.src/lib/Target/ARM/ARMISelLowering.h
The file was modified/llvm/trunk/lib/Target/ARM/ARMInstrVFP.td (diff)llvm.src/lib/Target/ARM/ARMInstrVFP.td
The file was modified/llvm/trunk/test/CodeGen/ARM/fp16-instructions.ll (diff)llvm.src/test/CodeGen/ARM/fp16-instructions.ll
The file was modified/llvm/trunk/test/CodeGen/Thumb2/float-ops.ll (diff)llvm.src/test/CodeGen/Thumb2/float-ops.ll
Revision 364908 by nico:
gn build: Merge r364866
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/utils/gn/secondary/clang/unittests/StaticAnalyzer/BUILD.gn (diff)llvm.src/utils/gn/secondary/clang/unittests/StaticAnalyzer/BUILD.gn
Revision 364907 by grimar:
[yaml2obj] - An attempt to fix a ppc64be build bot after r364898

I guess the problem is because of endianess of
the bytes tested by "od" tool. I changed the Content
sequence as it does not actually matter.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/test/tools/yaml2obj/elf-override-shoffset.yaml (diff)llvm.src/test/tools/yaml2obj/elf-override-shoffset.yaml
Revision 364906 by rksimon:
[X86] resolveTargetShuffleInputsAndMask - add repeated input handling.

We were relying on combineX86ShufflesRecursively to handle this - this patch gets it done earlier which should make it easier for other code to use resolveTargetShuffleInputsAndMask.
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (diff)llvm.src/lib/Target/X86/X86ISelLowering.cpp
Revision 364905 by grimar:
[test/Object] - Fix build bot.

Fixed mistype in the test case.

BB: http://lab.llvm.org:8011/builders/lld-x86_64-ubuntu-fast/builds/2720/steps/test-check-all/logs/stdio
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/test/Object/invalid.test (diff)llvm.src/test/Object/invalid.test
Revision 364904 by kadircet:
[clang][ArgumentAdjusters] Do not add fsyntax-only if already exists

Reviewers: hokein

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64063
Change TypePath in RepositoryPath in Workspace
The file was modified/cfe/trunk/lib/Tooling/ArgumentsAdjusters.cpp (diff)clang.src/lib/Tooling/ArgumentsAdjusters.cpp
The file was modified/cfe/trunk/unittests/Tooling/ToolingTest.cpp (diff)clang.src/unittests/Tooling/ToolingTest.cpp
Revision 364903 by grimar:
[Object/invalid.test] - Convert 3 more sub-tests to YAML

This allows to remove 3 more precompiled binaries from the inputs.

Differential revision: https://reviews.llvm.org/D63880
Change TypePath in RepositoryPath in Workspace
The file was removed/llvm/trunk/test/Object/Inputs/invalid-relocation-sec-sh_offset.elf-i386llvm.src/test/Object/Inputs/invalid-relocation-sec-sh_offset.elf-i386
The file was removed/llvm/trunk/test/Object/Inputs/invalid-relocation-sec-sh_offset.elf-x86-64llvm.src/test/Object/Inputs/invalid-relocation-sec-sh_offset.elf-x86-64
The file was removed/llvm/trunk/test/Object/Inputs/invalid-section-size2.elfllvm.src/test/Object/Inputs/invalid-section-size2.elf
The file was modified/llvm/trunk/test/Object/invalid.test (diff)llvm.src/test/Object/invalid.test
Revision 364902 by atanasyan:
[mips] Mark P5600 scheduling model as complete
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/Mips/MipsScheduleP5600.td (diff)llvm.src/lib/Target/Mips/MipsScheduleP5600.td
Revision 364901 by nico:
clang-cl: Make /d1reportAllClassLayout actually work and improve test

See review thread for r301567.
Change TypePath in RepositoryPath in Workspace
The file was modified/cfe/trunk/include/clang/Driver/CLCompatOptions.td (diff)clang.src/include/clang/Driver/CLCompatOptions.td
The file was modified/cfe/trunk/test/Driver/cl-options.c (diff)clang.src/test/Driver/cl-options.c
Revision 364900 by atanasyan:
[mips] Add missing schedinfo for FPU load/store/conv instructions
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/Mips/MipsScheduleP5600.td (diff)llvm.src/lib/Target/Mips/MipsScheduleP5600.td
Revision 364899 by atanasyan:
[mips] Map SNOP, NOP to the P5600Nop scheduler resource
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/Target/Mips/MipsScheduleP5600.td (diff)llvm.src/lib/Target/Mips/MipsScheduleP5600.td
Revision 364898 by grimar:
[yaml2obj] - Allow overriding sh_offset field from the YAML.

Some of our test cases are using objects which
has sections with a broken sh_offset field.

There was no way to set it from YAML until this patch.

Differential revision: https://reviews.llvm.org/D63879
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/include/llvm/ObjectYAML/ELFYAML.h (diff)llvm.src/include/llvm/ObjectYAML/ELFYAML.h
The file was modified/llvm/trunk/lib/ObjectYAML/ELFYAML.cpp (diff)llvm.src/lib/ObjectYAML/ELFYAML.cpp
The file was added/llvm/trunk/test/tools/yaml2obj/elf-override-shoffset.yamlllvm.src/test/tools/yaml2obj/elf-override-shoffset.yaml
The file was modified/llvm/trunk/tools/obj2yaml/elf2yaml.cpp (diff)llvm.src/tools/obj2yaml/elf2yaml.cpp
The file was modified/llvm/trunk/tools/yaml2obj/yaml2elf.cpp (diff)llvm.src/tools/yaml2obj/yaml2elf.cpp
Revision 364897 by lebedevri:
[NFC][InstCombine] Revisit tests for "redundant shift input masking" (PR42456)
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/test/Transforms/InstCombine/redundant-shift-input-masking.ll (diff)llvm.src/test/Transforms/InstCombine/redundant-shift-input-masking.ll
Revision 364896 by ikudrin:
[DWARF] Simplify dumping of a .debug_addr section.

This patch removes the part which tried to interpret addresses
in that section as offsets and simplifies the remaining code.

Differential Revision: https://reviews.llvm.org/D64020
Change TypePath in RepositoryPath in Workspace
The file was modified/llvm/trunk/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp (diff)llvm.src/lib/DebugInfo/DWARF/DWARFDebugAddr.cpp