| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
I knee-jerk tried to fix this in completely the wrong way - it's not an
CPU limitation, but an OS/object file type one, so moving it
into a CPU-specific classification didn't help at all.
llvm-svn: 249562
|
|
|
|
| |
llvm-svn: 249489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
differ from those in the declaration
This is handy for some AutoFDO stuff, and seems like a minor improvement
to correctness (otherwise a debug info consumer might think the decl
line/file of the def was the same as that of the declaration - though
what a consumer might use that for, I'm not sure - maybe "list <func>"
would've misbehaved with the old behavior?) and at a minor cost (in my
experiment, with fission, without type units, without compression, 0.01%
growth in debug info in the executable/objects, 0.02% growth in the .dwo
files).
llvm-svn: 249487
|
|
|
|
| |
llvm-svn: 249075
|
|
|
|
|
|
|
|
| |
The test requires X86 target support, and checks the actual debug
info contents, including register numbers which would be different on
other platforms.
llvm-svn: 248938
|
|
|
|
| |
llvm-svn: 248933
|
|
|
|
|
|
|
|
| |
You can show them with the new -dag-dump-verbose switch.
Differential Revision: http://reviews.llvm.org/D12566
llvm-svn: 248011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This gives us more human readable numbers to identify nodes in debug
dumps.
Before:
0x7fcbd9700160: ch = EntryToken
0x7fcbd985c7c8: i64 = Register %RAX
...
0x7fcbd9700160: <multiple use>
0x7fcbd985c578: i64,ch = MOV64rm 0x7fcbd985c6a0, 0x7fcbd985cc68, 0x7fcbd985c200, 0x7fcbd985cd90, 0x7fcbd985ceb8, 0x7fcbd9700160<Mem:LD8[@foo]> [ORD=2]
0x7fcbd985c8f0: ch,glue = CopyToReg 0x7fcbd9700160, 0x7fcbd985c7c8, 0x7fcbd985c578 [ORD=3]
0x7fcbd985c7c8: <multiple use>
0x7fcbd985c8f0: <multiple use>
0x7fcbd985c8f0: <multiple use>
0x7fcbd985ca18: ch = RETQ 0x7fcbd985c7c8, 0x7fcbd985c8f0, 0x7fcbd985c8f0:1 [ORD=3]
Now:
t0: ch = EntryToken
t5: i64 = Register %RAX
...
t0: <multiple use>
t3: i64,ch = MOV64rm t10, t12, t11, t13, t14, t0<Mem:LD8[@foo]> [ORD=2]
t6: ch,glue = CopyToReg t0, t5, t3 [ORD=3]
t5: <multiple use>
t6: <multiple use>
t6: <multiple use>
t7: ch = RETQ t5, t6, t6:1 [ORD=3]
Differential Revision: http://reviews.llvm.org/D12564
llvm-svn: 248010
|
|
|
|
|
|
|
| |
I couldn't see the failure as the test is XFAIL'ed on Darwin.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247776
|
|
When building LLVM as a (potentially dynamic) library that can be linked against
by multiple compilers, the default triple is not really meaningful.
We allow to explicitely set it to an empty string when configuring LLVM.
In this case, said "target independent" tests in the test suite that are using
the default triple are disabled by matching the newly available feature
"default_triple".
Reviewers: probinson, echristo
Differential Revision: http://reviews.llvm.org/D12660
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 247775
|