jmorse wrote:
> @jmorse What do you think about merging this PR to the release branch?
I feel this is safe to go into the release branch; I don't think it should
block the 19.0.0 release though, better to have it in a point release. This
fault has been present for roughly five months and has o
https://github.com/jmorse approved this pull request.
As with the previous rev, LGTM as a fix for an edge case. This situation has
taken many months to expose, so I don't think it urgently needs to go into the
imminent release, a point release should be fine.
https://github.com/llvm/llvm-proje
Author: Jeremy Morse
Date: 2021-07-29T15:08:13+01:00
New Revision: 6b2e4c5a58d7f75f52b740bd7d96dc3a00b7ef6c
URL:
https://github.com/llvm/llvm-project/commit/6b2e4c5a58d7f75f52b740bd7d96dc3a00b7ef6c
DIFF:
https://github.com/llvm/llvm-project/commit/6b2e4c5a58d7f75f52b740bd7d96dc3a00b7ef6c.diff
Author: Jeremy Morse
Date: 2021-01-20T11:46:11Z
New Revision: eff6e75c3f7c5471f0326526dc3f0b8b10f8a4df
URL:
https://github.com/llvm/llvm-project/commit/eff6e75c3f7c5471f0326526dc3f0b8b10f8a4df
DIFF:
https://github.com/llvm/llvm-project/commit/eff6e75c3f7c5471f0326526dc3f0b8b10f8a4df.diff
LOG:
Author: Jeremy Morse
Date: 2021-01-05T10:25:37Z
New Revision: 914066fe38a93c004b742a696ec337701eb738ec
URL:
https://github.com/llvm/llvm-project/commit/914066fe38a93c004b742a696ec337701eb738ec
DIFF:
https://github.com/llvm/llvm-project/commit/914066fe38a93c004b742a696ec337701eb738ec.diff
LOG:
Author: Nabeel Omer
Date: 2020-12-17T16:17:32Z
New Revision: df2b9a3e02ca3bd7b60af6c65571909a7d3ab317
URL:
https://github.com/llvm/llvm-project/commit/df2b9a3e02ca3bd7b60af6c65571909a7d3ab317
DIFF:
https://github.com/llvm/llvm-project/commit/df2b9a3e02ca3bd7b60af6c65571909a7d3ab317.diff
LOG: [
Author: Jeremy Morse
Date: 2020-12-08T11:01:55Z
New Revision: cda32aba4f46033eea4eea6eda703459dc3c7a1e
URL:
https://github.com/llvm/llvm-project/commit/cda32aba4f46033eea4eea6eda703459dc3c7a1e
DIFF:
https://github.com/llvm/llvm-project/commit/cda32aba4f46033eea4eea6eda703459dc3c7a1e.diff
LOG:
@@ -23,8 +24,8 @@ void f(int m) {
}
// CHECK: TypeSanitizer: type-aliasing-violation on address
- // CHECK-NEXT: READ of size 2 at {{.+}} with type short accesses an existing
object of type long long
- // CHECK-NEXT:in f violation-pr47137.c:30
+ // CHECK-NEXT:
@@ -18,7 +18,7 @@ int main(void) {
// CHECK: TypeSanitizer: type-aliasing-violation on address
// CHECK-NEXT: WRITE of size 8 at {{.+}} with type double accesses an
existing object of type float
- // CHECK-NEXT: in main violation-pr45282.c:25
+ // CHECK-NEXT: i
@@ -221,7 +221,24 @@ __tysan_check(void *addr, int size, tysan_type_descriptor
*td, int flags) {
OldTDPtr -= i;
OldTD = *OldTDPtr;
-if (!isAliasingLegal(td, OldTD))
+// When shadow memory is set for global objects, the entire object is
tagged with the struct
https://github.com/jmorse commented:
I'm not familiar with TySan, but here's some style feedback and similar inline.
The comments in tysan.cpp are too long (clang-format-bot would have bitten you
if it was live when you uploaded this), please clang-format.
https://github.com/llvm/llvm-project/
https://github.com/jmorse edited https://github.com/llvm/llvm-project/pull/95387
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,31 @@
+// RUN: %clang_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
+// RUN: FileCheck %s < %t.out
+
+#include
+
+struct X {
+ int a, b, c;
+} x;
+
+static struct X xArray[2];
+
+int main() {
+ x.a = 1;
+ x.b = 2;
+ x.c = 3;
+
+ printf("%d %d %d\n", x.a, x.b, x.c);
+
@@ -221,7 +221,24 @@ __tysan_check(void *addr, int size, tysan_type_descriptor
*td, int flags) {
OldTDPtr -= i;
OldTD = *OldTDPtr;
-if (!isAliasingLegal(td, OldTD))
+// When shadow memory is set for global objects, the entire object is
tagged with the struct
@@ -221,7 +221,17 @@ __tysan_check(void *addr, int size, tysan_type_descriptor
*td, int flags) {
OldTDPtr -= i;
OldTD = *OldTDPtr;
-if (!isAliasingLegal(td, OldTD))
+tysan_type_descriptor *InternalMember = OldTD;
jmorse wrote:
I feel like you
@@ -0,0 +1,31 @@
+// RUN: %clang_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
+// RUN: FileCheck %s < %t.out
+
+#include
+
+struct X {
+ int a, b, c;
+} x;
+
+static struct X xArray[2];
+
+int main() {
+ x.a = 1;
+ x.b = 2;
+ x.c = 3;
+
+ printf("%d %d %d\n", x.a, x.b, x.c);
+
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/108385
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -128,6 +128,10 @@ static bool isAliasingLegalUp(tysan_type_descriptor *TDA,
break;
}
+ //You can't have negative offset, you must be partially inside the last
type
jmorse wrote:
Space at start of comment; better to write the comment i
@@ -0,0 +1,31 @@
+// RUN: %clangxx_tysan -O0 %s -o %t && %run %t >%t.out 2>&1
+// RUN: FileCheck %s < %t.out
+
+#include
+
+struct inner {
+ char buffer;
+ int i;
+};
+
+void init_inner(inner *iPtr) {
+ iPtr->i = 0;
+}
+
+struct outer {
+ inner foo;
+c
https://github.com/jmorse commented:
(Minor style and test feedbacks)
https://github.com/llvm/llvm-project/pull/108385
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-c
https://github.com/jmorse commented:
Are there any expected interactions between atom-group-numbers and loading
bitcode? i.e., if we serialise the literal atom-group-number to the output and
then read it back in again, then it might conflict with atom-group-numbers seen
in other functions in o
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133478
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1366,6 +1367,43 @@ TEST_F(DILocationTest, discriminatorSpecialCases) {
EXPECT_EQ(std::nullopt, L4->cloneByMultiplyingDuplicationFactor(0x1000));
}
+TEST_F(DILocationTest, KeyInstructions) {
+ Context.pImpl->NextAtomGroup = 1;
+
+ EXPECT_EQ(Context.pImpl->NextAtomGroup,
@@ -335,6 +335,14 @@ class LLVMContext {
StringRef getDefaultTargetFeatures();
void setDefaultTargetFeatures(StringRef Features);
+ /// Key Instructions: update the highest number atom group emitted for any
+ /// function.
+ void updateAtomGroupWaterline(uint64_t G);
+
@@ -87,6 +87,8 @@ class ValueMap {
using ValueMapCVH = ValueMapCallbackVH;
using MapT = DenseMap>;
using MDMapT = DenseMap;
+ /// Map {(InlinedAt, old atom number) -> new atom number}.
+ using DMAtomT = DenseMap, uint64_t>;
jmorse wrote:
Consider using
@@ -105,6 +105,13 @@ enum RemapFlags {
/// Any global values not in value map are mapped to null instead of mapping
/// to self. Illegal if RF_IgnoreMissingLocals is also set.
RF_NullMapMissingGlobalValues = 8,
+
+ /// Do not remap atom instances. Only safe if to do thi
@@ -117,9 +118,21 @@ struct ClonedCodeInfo {
/// If you would like to collect additional information about the cloned
/// function, you can specify a ClonedCodeInfo object with the optional fifth
/// parameter.
+///
+/// Set \p MapAtoms to false to skip mapping source atoms for
@@ -105,6 +105,13 @@ enum RemapFlags {
/// Any global values not in value map are mapped to null instead of mapping
/// to self. Illegal if RF_IgnoreMissingLocals is also set.
RF_NullMapMissingGlobalValues = 8,
+
+ /// Do not remap atom instances. Only safe if to do thi
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133479
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -105,6 +105,13 @@ enum RemapFlags {
/// Any global values not in value map are mapped to null instead of mapping
/// to self. Illegal if RF_IgnoreMissingLocals is also set.
RF_NullMapMissingGlobalValues = 8,
+
+ /// Do not remap atom instances. Only safe if to do thi
https://github.com/jmorse approved this pull request.
LGTM, code and tests are good. As ever all my comments are about comments and
maintainability!
https://github.com/llvm/llvm-project/pull/133479
___
llvm-branch-commits mailing list
llvm-branch-comm
@@ -284,6 +291,9 @@ inline void RemapInstruction(Instruction *I,
ValueToValueMapTy &VM,
.remapInstruction(*I);
}
+/// Remap source atom. Called by RemapInstruction.
jmorse wrote:
IMO too terse; needs some purpose and context.
https://github.com/llvm/l
https://github.com/jmorse approved this pull request.
LGTM, although I'm not especially familiar with the transition to the new pass
manager.
https://github.com/llvm/llvm-project/pull/131563
___
llvm-branch-commits mailing list
llvm-branch-commits@lis
@@ -77,36 +78,68 @@ class LiveDebugValues : public MachineFunctionPass {
AU.setPreservesCFG();
MachineFunctionPass::getAnalysisUsage(AU);
}
+};
+
+struct LiveDebugValues {
+ LiveDebugValues();
+ ~LiveDebugValues() = default;
+ bool run(MachineFunction &MF, bool Sho
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/131563
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse commented:
Looks good, although I think the atom-group selection could be refactored so
that it's simpler to read. There's already multiple levels of nesting happening
in that function, best to reduce that as much as possible (possibly put it in a
completely different
@@ -226,8 +230,44 @@ DILocation *DILocation::getMergedLocation(DILocation
*LocA, DILocation *LocB) {
bool SameCol = L1->getColumn() == L2->getColumn();
unsigned Line = SameLine ? L1->getLine() : 0;
unsigned Col = SameLine && SameCol ? L1->getColumn() : 0;
-
-re
@@ -1243,6 +1243,140 @@ TEST_F(DILocationTest, Merge) {
auto *M2 = DILocation::getMergedLocation(A2, B);
EXPECT_EQ(M1, M2);
}
+
+#ifdef EXPERIMENTAL_KEY_INSTRUCTIONS
+#define EXPECT_ATOM(Loc, Group, Rank)
\
+ EXPECT_EQ(Group,
@@ -1243,6 +1243,140 @@ TEST_F(DILocationTest, Merge) {
auto *M2 = DILocation::getMergedLocation(A2, B);
EXPECT_EQ(M1, M2);
}
+
+#ifdef EXPERIMENTAL_KEY_INSTRUCTIONS
+#define EXPECT_ATOM(Loc, Group, Rank)
\
+ EXPECT_EQ(Group,
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133480
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133482
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse commented:
Looks good, question inline. I worried a little about whether someone out there
might inadvertantly re-use this function for some other purpose, but it looks
like it's dedicated to `llvm::foldBranchToCommonDest`, so pretty much a single
use case.
https://g
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/133483
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1129,13 +1130,17 @@ static void
cloneInstructionsIntoPredecessorBlockAndUpdateSSAUses(
Instruction *NewBonusInst = BonusInst.clone();
-if (!isa(BonusInst) &&
-PTI->getDebugLoc() != NewBonusInst->getDebugLoc()) {
- // Unless the instruction has the sa
@@ -0,0 +1,81 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
UTC_ARGS: --version 5
+; RUN: opt %s -S -passes=simplifycfg -bonus-inst-threshold=2 | FileCheck %s
+
+;; Block d gets folded into preds b and c. Check the cloned instructions get
-
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/133484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse approved this pull request.
LGTM with nit
https://github.com/llvm/llvm-project/pull/133485
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133485
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1821,9 +1821,9 @@ static DebugLoc inlineDebugLoc(DebugLoc OrigDL,
DILocation *InlinedAt,
/// to encode location where these instructions are inlined.
static void fixupLineNumbers(Function *Fn, Function::iterator FI,
Instruction *TheCall, bool C
@@ -2314,6 +2326,7 @@ void
JumpThreadingPass::threadThroughTwoBasicBlocks(BasicBlock *PredPredBB,
{DominatorTree::Insert, PredPredBB, NewBB},
{DominatorTree::Delete, PredPredBB, PredBB}});
+ remapSourceAtoms(ValueMapping, NewBB->begin(), NewBB->end());
@@ -0,0 +1,68 @@
+; RUN: opt -S -passes=jump-threading,verify %s | FileCheck %s
+
+;; Modified from llvm/test/Transforms/JumpThreading/thread-two-bbs.ll
+;;
+;; JumpThreading duplicates bb.cond2 to thread through bb.file to bb.f2 or
exit.
+;;
+;; Check the duplicated instructions
@@ -2087,8 +2097,10 @@ void
JumpThreadingPass::cloneInstructions(ValueToValueMapTy &ValueMapping,
adaptNoAliasScopes(New, ClonedScopes, Context);
CloneAndRemapDbgInfo(New, &*BI);
+if (const DebugLoc &DL = New->getDebugLoc())
+ mapAtomInstance(DL, ValueMapping
https://github.com/jmorse approved this pull request.
LGTM with nits
https://github.com/llvm/llvm-project/pull/133486
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-co
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133486
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133487
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,78 @@
+; RUN: opt %s --passes=jump-threading -S -o - -S | FileCheck %s
+
+;;+-> T1 -+
+;;| v +-> T2
+;; Entry -+ Merge -+
+;;| ^ +-> F2
+;;+-> F1 -+
+;;
+;; Thread T1 -> T2 and F1 -> F2 through Merge.
+;;
+;;
https://github.com/jmorse commented:
The previous patch in this stack #133486 calls remapSourceAtoms before calling
calling threadEdge; and this patch adds a call to remapSourceAtoms into
threadEdge, so it'll be called twice. Is this just inconsequential or
deliberate, or meaningless?
https:
https://github.com/jmorse approved this pull request.
Whilst being some complicated threading, LGTM
https://github.com/llvm/llvm-project/pull/133488
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133489
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -752,6 +752,14 @@ llvm::UnrollLoop(Loop *L, UnrollLoopOptions ULO, LoopInfo
*LI,
}
}
+ // Remap source location atom instance. Do this now, rather than
+ // when we remap instructions, because remap is called once we've
+ // cloned all blocks (
https://github.com/jmorse commented:
Looks good, but question inline
https://github.com/llvm/llvm-project/pull/133489
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-co
https://github.com/jmorse approved this pull request.
LGTM (although the hand-written tests are more fun and easier to read)
https://github.com/llvm/llvm-project/pull/133490
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https:
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133490
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse approved this pull request.
Seems fine, but the test is hard to decipher, future generations will praise us
if it can be simplified.
https://github.com/llvm/llvm-project/pull/133491
___
llvm-branch-commits mailing list
llvm-b
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133495
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jmorse wrote:
It can't hurt, let's making things slightly more correct!
https://github.com/llvm/llvm-project/pull/133492
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
@@ -0,0 +1,78 @@
+# RUN: llc %s --start-after=livedebugvalues --dwarf-use-key-instructions
--filetype=obj -o - \
+# RUN: | llvm-objdump -d - --no-show-raw-insn \
+# RUN: | FileCheck %s --check-prefix=OBJ
+
+# RUN: llc %s --start-after=livedebugvalues --dwarf-use-key-instructions
@@ -0,0 +1,117 @@
+; RUN: llc %s --filetype=obj -o - --dwarf-use-key-instructions \
+; RUN: | llvm-objdump -d - --no-show-raw-insn \
+; RUN: | FileCheck %s --check-prefix=OBJ
+
+; RUN: llc %s --filetype=obj -o - --dwarf-use-key-instructions \
+; RUN: | llvm-dwarfdump - --debug-lin
https://github.com/jmorse commented:
Tests: I'd personally prefer the input source and explanation at the top of the
file, although this is a style thing.
My understanding of this code is that within a basic block, it should be
possible for there to be two sequences of instructions of equal gr
https://github.com/jmorse approved this pull request.
I continued my ramblings inline; I see the potential for some slightly
unexpected stepping behaviour, but still strictly better than todays
"everything is a breakpoint" approach. I don't think I can put my finger on a
specific bad behaviour
@@ -1243,6 +1243,140 @@ TEST_F(DILocationTest, Merge) {
auto *M2 = DILocation::getMergedLocation(A2, B);
EXPECT_EQ(M1, M2);
}
+
+#ifdef EXPERIMENTAL_KEY_INSTRUCTIONS
+#define EXPECT_ATOM(Loc, Group, Rank)
\
+ EXPECT_EQ(Group,
https://github.com/jmorse approved this pull request.
LGTM with the style nits
https://github.com/llvm/llvm-project/pull/133478
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133495
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -2087,13 +2095,18 @@ void DwarfDebug::beginInstruction(const MachineInstr
*MI) {
// If we have an ongoing unspecified location, nothing to do here.
if (!DL)
return;
-// We have an explicit location, same as the previous location.
-// But we might be co
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
https://github.com/jmorse commented:
I get the impression that `GroupCandidates` and `KeyInstructions` are being
kept strictly in sync; thus couldn't one instead just load KeyInstructions from
GroupCandidates once the scan is complete? This avoids filling up the dense map
with tombstones.
Am
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
@@ -2333,6 +2352,170 @@ DwarfDebug::emitInitialLocDirective(const
MachineFunction &MF, unsigned CUID) {
return PrologEndLoc;
}
+void DwarfDebug::findKeyInstructions(const MachineFunction *MF) {
+ // New function - reset KeyInstructions.
+ KeyInstructions.clear();
+
+ //
@@ -1129,13 +1130,17 @@ static void
cloneInstructionsIntoPredecessorBlockAndUpdateSSAUses(
Instruction *NewBonusInst = BonusInst.clone();
-if (!isa(BonusInst) &&
-PTI->getDebugLoc() != NewBonusInst->getDebugLoc()) {
- // Unless the instruction has the sa
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133482
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jmorse edited
https://github.com/llvm/llvm-project/pull/133493
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -0,0 +1,52 @@
+; RUN: opt -passes='require,function(codegenprepare)' -S
-mtriple=x86_64 < %s \
+; RUN: | FileCheck %s
+
+;; Check debug locations are propagated onto new PHIs.
jmorse wrote:
"...and that source locations have their atom groups remapped"
https
https://github.com/jmorse approved this pull request.
LGTM with nit
https://github.com/llvm/llvm-project/pull/133493
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-com
https://github.com/jmorse approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/133494
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jmorse wrote:
Github has helpfully chucked away my comments; was the unit-test-error that I
fixed corrected? If so, LGTM.
https://github.com/llvm/llvm-project/pull/133480
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://
@@ -0,0 +1,2348 @@
+//===-- LVIRReader.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: A
https://github.com/jmorse commented:
Some initial comments; I made it to about 1000 lines into LVIRReader.cpp.
https://github.com/llvm/llvm-project/pull/135440
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.o
@@ -0,0 +1,300 @@
+//===-- LVIRReader.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -728,14 +514,16 @@ void LVDWARFReader::createLineAndFileRecords(
for (const DWARFDebugLine::FileNameEntry &Entry :
Lines->Prologue.FileNames) {
std::string Directory;
- if (Lines->getDirectoryForEntry(Entry, Directory))
-Directory = transformP
@@ -0,0 +1,2348 @@
+//===-- LVIRReader.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: A
@@ -0,0 +1,300 @@
+//===-- LVIRReader.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,2348 @@
+//===-- LVIRReader.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: A
@@ -2124,6 +2125,138 @@ layout and given the number of matches.
-
Total 71 8
+IR (Textual representation and bitcode) SUPPORT
+~~~
+The below example is used to show the IR output ge
@@ -0,0 +1,300 @@
+//===-- LVIRReader.h *- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,2348 @@
+//===-- LVIRReader.cpp
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: A
@@ -56,6 +61,17 @@ Error LVReaderHandler::createReader(StringRef Filename,
LVReaders &Readers,
return std::make_unique(Filename, FileFormatName, Pdb,
W, ExePath);
}
+if (isa(Input)) {
+ IRObjectFile *Ir = cast(
1 - 100 of 182 matches
Mail list logo
