Skip to content

Merge and use StringRef in getPassName (NFC) #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 84 commits into from
Oct 3, 2016
Merged

Merge and use StringRef in getPassName (NFC) #17

merged 84 commits into from
Oct 3, 2016

Conversation

kzhuravl
Copy link

@kzhuravl kzhuravl commented Oct 3, 2016

No description provided.

Quentin Colombet and others added 30 commits September 30, 2016 21:45
Avoid to rely on the dynamically allocated operands mapping for the
alternative mapping.
NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282956 91177308-0d34-0410-b5e6-96231b3b80d8
The function name did not make it clear that the returned value was an
offset to apply to a register bank index.

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282957 91177308-0d34-0410-b5e6-96231b3b80d8
…apping

Use a helper function to access ValMapping. This should make the code
easier to understand and maintain.

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282958 91177308-0d34-0410-b5e6-96231b3b80d8
We don't need to have singleton ValueMapping on their own, we can just
reuse one of the elements of the 3-ops mapping.
This allows even more code sharing.

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282959 91177308-0d34-0410-b5e6-96231b3b80d8
We don't return index, we return the actual ValueMapping.

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282960 91177308-0d34-0410-b5e6-96231b3b80d8
This makes sure the helper functions work as expected.

NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282961 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids errors about references to undefined local labels from
unreferenced filter functions.

Fixes (sort of) PR30431

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282967 91177308-0d34-0410-b5e6-96231b3b80d8
…d LTO dead-stripping

The binder is in a specific section that "reverse" the edges in a
regular dead-stripping: the binder is live as long as a global it
references is live.

This is a big hammer that prevents LLVM from dead-stripping these,
while still allowing linker dead-stripping (with special knowledge
of the section).

Differential Revision: https://reviews.llvm.org/D24673

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282988 91177308-0d34-0410-b5e6-96231b3b80d8
To lex hash directives we peek ahead to find component tokens, create a
unified token, and unlex the peeked tokens so the parser does not need
to parse the tokens then. Make sure we do not to lex another hash
directive during peek operation.

This fixes PR28921.

Reviewers: rnk, loladiro

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D24839

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282992 91177308-0d34-0410-b5e6-96231b3b80d8
…s of the corpus smaller, off by default

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282995 91177308-0d34-0410-b5e6-96231b3b80d8
This removes many re-initializations of a base register to 0.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282999 91177308-0d34-0410-b5e6-96231b3b80d8
and can be pulled from the TargetMachine. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283000 91177308-0d34-0410-b5e6-96231b3b80d8
TargetTriple, just grab it off of the TargetMachine. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283001 91177308-0d34-0410-b5e6-96231b3b80d8
of the TargetMachine. NFC.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283002 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r283009. Bots are broken.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283011 91177308-0d34-0410-b5e6-96231b3b80d8
RKSimon and others added 28 commits October 1, 2016 16:30
As per the PE COFF spec (section 8.3, Import Name Type)
Offset: 18 Size 2 bits Name: Type
Offset: 20 Size 3 bits Name: Name Type

Offset: 20 added based on 18+2

Partially commited as rL279069

Differential Revision: https://reviews.llvm.org/D23540

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283055 91177308-0d34-0410-b5e6-96231b3b80d8
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283057 91177308-0d34-0410-b5e6-96231b3b80d8
ICmpInst::makeConstantRange does exactly the same thing as
ConstantRange::makeExactICmpRegion.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283059 91177308-0d34-0410-b5e6-96231b3b80d8
This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.

Fixes PR26970.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283060 91177308-0d34-0410-b5e6-96231b3b80d8
They've broken the sanitizer-bootstrap bots.  Reverting while I investigate.

Original commit messages:

r283057: "[ConstantRange] Make getEquivalentICmp smarter"

r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI"

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283062 91177308-0d34-0410-b5e6-96231b3b80d8
… 64-bit. This way we don't have to catch them and do nothing with them in ReplaceNodeResults.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283066 91177308-0d34-0410-b5e6-96231b3b80d8
To allow broadcast loads of a non-zero'th vector element, lowerVectorShuffleAsBroadcast can replace a load with a new load with an adjusted address, but unfortunately we weren't ensuring that the new load respected the same dependencies.

This patch adds a TokenFactor and updates all dependencies of the old load to reference the new load instead.

Bug found during internal testing.

Differential Revision: https://reviews.llvm.org/D25039

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283070 91177308-0d34-0410-b5e6-96231b3b80d8
Preemptively scrubbing these to avoid a bot fail as in PR30443:
https://llvm.org/bugs/show_bug.cgi?id=30443

I'm nearly done with a patch to fix these cases, so not trying very
hard to do better for the temporary win. 

I plan to use better checks than what the script produces for the vectorized cases.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283072 91177308-0d34-0410-b5e6-96231b3b80d8
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283074 91177308-0d34-0410-b5e6-96231b3b80d8
We are testing vpermps not vpermd

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283076 91177308-0d34-0410-b5e6-96231b3b80d8
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.

An earlier version of this change was landed as rL283057 which had a
use-after-free bug.  This new version has a fix for that bug, and a (C++
unittests/) test case that would have triggered it rL283057.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283078 91177308-0d34-0410-b5e6-96231b3b80d8
This was first landed in rL283058 and subsequenlty reverted since a
change this depends on (rL283057) was buggy and had to be reverted.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@283079 91177308-0d34-0410-b5e6-96231b3b80d8
@tstellarAMD tstellarAMD merged commit c38fe1f into ROCm:amd-common Oct 3, 2016
kzhuravl pushed a commit that referenced this pull request Dec 29, 2017
Summary:
I have been getting rather difficult to reproduce SIGBUS crashes when
compiling certain FreeBSD sources, and their stack traces pointed
squarely at `SelectionDAG::salvageDebugInfo()`:

```
Core was generated by `/usr/obj/share/dim/src/freebsd/clang600-import/amd64.amd64/tmp/usr/bin/cc -cc1 -'.
Program terminated with signal SIGBUS, Bus error.
#0  isInvalidated () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SDNodeDbgValue.h:115
115       bool isInvalidated() const { return Invalid; }
(gdb) bt
#0  isInvalidated () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SDNodeDbgValue.h:115
#1  salvageDebugInfo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7116
#2  0x00000000033b2516 in operator() () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3595
#3  __invoke<(lambda at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3593:59) &, llvm::SDNode *, llvm::SDNode *> () at /usr/include/c++/v1/type_traits:4323
#4  __call<(lambda at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3593:59) &, llvm::SDNode *, llvm::SDNode *> () at /usr/include/c++/v1/__functional_base:349
#5  operator() () at /usr/include/c++/v1/functional:1562
#6  0x00000000033b0817 in operator() () at /usr/include/c++/v1/functional:1916
#7  NodeDeleted () at /share/dim/src/freebsd/clang600-import/contrib/llvm/include/llvm/CodeGen/SelectionDAG.h:293
#8  0x0000000003529dde in RemoveDeadNodes () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:610
#9  0x00000000035556df in MorphNodeTo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:6794
#10 0x00000000033a9acc in MorphNode () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2594
#11 0x00000000033ac80b in SelectCodeCommon () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3601
#12 0x00000000023d464b in SelectCode () at /usr/obj/share/dim/src/freebsd/clang600-import/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/X86GenDAGISel.inc:282902
#13 Select () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:3072
#14 0x00000000033a5afa in DoInstructionSelection () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:988
#15 0x00000000033a4e1a in CodeGenAndEmitDAG () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:868
#16 0x00000000033a2643 in SelectAllBasicBlocks () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1624
#17 0x000000000339f158 in runOnMachineFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:466
#18 0x00000000023d03c4 in runOnMachineFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/Target/X86/X86ISelDAGToDAG.cpp:175
#19 0x00000000035cc8c2 in runOnFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/MachineFunctionPass.cpp:62
#20 0x00000000030dca9a in runOnFunction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1520
#21 0x00000000030dccf3 in runOnModule () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1541
#22 0x00000000030dd228 in runOnModule () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1597
#23 run () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/IR/LegacyPassManager.cpp:1700
#24 0x00000000014db578 in EmitAssembly () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:815
#25 EmitBackendOutput () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1181
#26 0x00000000014d5b26 in HandleTranslationUnit () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:292
#27 0x0000000001c4c332 in ParseAST () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Parse/ParseAST.cpp:159
#28 0x00000000015d546c in Execute () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:897
#29 0x0000000001cec311 in ExecuteAction () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:991
#30 0x00000000014b4f81 in ExecuteCompilerInvocation () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252
#31 0x00000000014aa73f in cc1_main () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/cc1_main.cpp:221
#32 0x00000000014b2928 in ExecuteCC1Tool () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/driver.cpp:309
#33 main () at /share/dim/src/freebsd/clang600-import/contrib/llvm/tools/clang/tools/driver/driver.cpp:388
(gdb) frame 1
#1  salvageDebugInfo () at /share/dim/src/freebsd/clang600-import/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:7116
7116        if (DV->isInvalidated())
(gdb) disassemble
Dump of assembler code for function salvageDebugInfo():
[...]
   0x0000000003557348 <+744>:   nopl   0x0(%rax,%rax,1)
   0x0000000003557350 <+752>:   mov    (%r12),%r13
=> 0x0000000003557354 <+756>:   cmpb   $0x0,0x31(%r13)
   0x0000000003557359 <+761>:   jne    0x35573b0 <salvageDebugInfo()+848>
(gdb) info registers
[...]
r13            0x5a5a5a5a5a5a5a5a       6510615555426900570
```

The `0x5a5a5a5a5a5a5a5a` value in `r13` indicates the memory was either
uninitialized, or already freed.

Unfortunately I do not have a simple self-contained test case for this.
However, it seems pretty clear that the call to `AddDbgValue()` in
`salvageDebugInfo()` causes the problems, since it modifies
`SelectionDag::DbgInfo` while looping through one of its DenseMaps:

```
void SelectionDAG::salvageDebugInfo(SDNode &N) {
[...]
  for (auto DV : GetDbgValues(&N)) {
    if (DV->isInvalidated())
      continue;
[...]
        AddDbgValue(Clone, N0.getNode(), false);
[...]
  }
}
```

At least, if I comment out the `AddDbgValue()` call, the crashes go
away.  I propose to change this function slightly, similar to the
`SelectionDAG::transferDbgValues()` function just above it, to save the
cloned SDDbgValues in a separate SmallVector, and only call
AddDbgValue() on them after the for loop is done.

Reviewers: aprantl, bogner, bkramer, davide

Reviewed By: davide

Subscribers: davide, krytarowski, JDevlieghere, emaste, llvm-commits

Differential Revision: https://reviews.llvm.org/D41589


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@321545 91177308-0d34-0410-b5e6-96231b3b80d8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.