| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20476
llvm-svn: 270552
|
| |
|
|
|
|
|
|
| |
second argument to buildin function but it is first instruction operand.
Differential Revision: http://reviews.llvm.org/D20515
llvm-svn: 270548
|
| |
|
|
|
|
|
|
| |
Failed build bot in another test.
I am sorry for noise.
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/23679/testReport/junit/LLVM/DebugInfo/llvm_symbolizer_zlib_test/
llvm-svn: 270547
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fix: forgot to commit the updated dwarfdump-test-zlib.elf-x86-64
Original commit message:
[llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.
Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style.
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.
Differential revision: http://reviews.llvm.org/D20470
llvm-svn: 270543
|
| |
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: The type of Imm in MipsDisassembler.cpp was incorrect since SignExtend64 return int64_t type.As per the MIPSr6 doc ,the offset is added to the address of the instruction following the branch (not the branch itself), to form a PC-relative effective target address hence “4” is added to the offset. The offset of some test case are update to reflect the changes due to “ + 4 ” offset and new test case for negative offset are added.
Reviewers: dsanders, vkalintiris
Differential Revision: http://reviews.llvm.org/D17540
llvm-svn: 270542
|
| |
|
|
|
|
|
|
|
| |
sections in zlib style."
it broked bot:
http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/5036
llvm-svn: 270541
|
| |
|
|
|
|
|
|
|
|
|
| |
Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers,
this patch adds support for zlib style.
It looks reasonable to support both styles for dumping,
even if we are not going to suport generating of deprecated gnu one.
Differential revision: http://reviews.llvm.org/D20470
llvm-svn: 270540
|
| |
|
|
|
|
| |
Now that we have a nice fast VPPERM solution. Added framework for future intrinsic costs as well.
llvm-svn: 270537
|
| |
|
|
| |
llvm-svn: 270529
|
| |
|
|
|
|
|
|
|
| |
default.""
This reverts commit r270512 and reapplies r270478. Originally it caused
PR27847, but it was fixed in r270517.
llvm-svn: 270518
|
| |
|
|
|
|
| |
This fixes PR27847.
llvm-svn: 270517
|
| |
|
|
| |
llvm-svn: 270516
|
| |
|
|
|
|
|
| |
This was actually meant to go in with r267966, but I forgot to
git add the file. Better late than never.
llvm-svn: 270515
|
| |
|
|
| |
llvm-svn: 270513
|
| |
|
|
|
|
| |
This caused PR27847.
llvm-svn: 270512
|
| |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20534
Reviewed By: rnk
llvm-svn: 270511
|
| |
|
|
|
|
|
|
|
|
| |
The logic that sets up lit features for sanitizers is largely copied
between here and clang, except clang's was fixed some time ago to
handle multiple sanitizers (ie, Asan + Ubsan). This just makes the
code in LLVM consistent with how it's done in clang to avoid any
gotchas by users of this.
llvm-svn: 270510
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Moved the ModuleLoader and supporting helper loadModuleFromBuffer out of
ThinLTOCodeGenerator and into new LTO.h/LTO.cpp files. This is in
preparation for a patch that will utilize these in the gold-plugin.
Note that there are some other pending patches (D20268 and D20290) that
also plan to refactor common interfaces and functionality into this same
pair of new files.
llvm-svn: 270509
|
| |
|
|
| |
llvm-svn: 270508
|
| |
|
|
| |
llvm-svn: 270507
|
| |
|
|
| |
llvm-svn: 270503
|
| |
|
|
|
|
|
|
| |
old xar.h header.
Reviewed the change with Chris Bieneman and Pete Cooper.
llvm-svn: 270502
|
| |
|
|
|
|
| |
match D20528
llvm-svn: 270501
|
| |
|
|
|
|
|
|
|
|
| |
This changes IRCE to optimize uses, and not branches. This change is
NFCI since the uses we do inspect are in practice only ever going to be
the condition use in conditional branches; but this flexibility will
later allow us to analyze more complex expressions than just a direct
branch on a range check.
llvm-svn: 270500
|
| |
|
|
| |
llvm-svn: 270498
|
| |
|
|
|
|
| |
since D13002!)
llvm-svn: 270497
|
| |
|
|
| |
llvm-svn: 270496
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19640
llvm-svn: 270495
|
| |
|
|
|
|
| |
Added D20528 implementations as well as existing x86 intrinsics versions
llvm-svn: 270494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before r269750 we did the comparisons in this loop in signed ints so
that it DTRT when MinCSFrameIndex was 0. This was changed because it's
now possible for MinCSFrameIndex to be UINT_MAX, but that introduced a
bug when we were comparing `>= 0` - this is tautological in unsigned.
Rework the comparisons here to avoid issues with unsigned wrapping.
No test. I couldn't find a way to get any of the StackGrowsUp in-tree
targets to reach the code that sets MinCSFrameIndex.
llvm-svn: 270492
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
"verbosely"
to llvm-objdump. This section is created with -fembed-bitcode option.
This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!
rdar://26202242
llvm-svn: 270491
|
| |
|
|
|
|
| |
intrinsic call
llvm-svn: 270489
|
| |
|
|
|
|
|
|
|
| |
This is a work in progress - the chapter text is incomplete, though
the example code compiles and runs.
Feedback and patches are, as usual, most welcome.
llvm-svn: 270487
|
| |
|
|
|
|
|
|
|
| |
They were accidentally using the 32-bit load/store instruction for
8/16-bit operations, due to incorrect patterns
(8/16-bit cmpxchg and atomicrmw will be fixed in subsequent changes)
llvm-svn: 270486
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This effectively revers commit r270389 and re-lands r270106, but it's
almost a rewrite.
The behavior change in r270106 was that we could no longer assume that
each LF_FUNC_ID record got its own type index. This patch adds a map
from DINode* to TypeIndex, so we can stop making that assumption.
This change also emits padding bytes between type records similar to the
way MSVC does. The size of the type record includes the padding bytes.
llvm-svn: 270485
|
| |
|
|
|
|
|
|
| |
to query interfaces argument; NFC
Differential Revision: http://reviews.llvm.org/D20532
llvm-svn: 270481
|
| |
|
|
| |
llvm-svn: 270480
|
| |
|
|
|
|
|
|
|
|
| |
When an aggregate contains an opaque type its size cannot be
determined. This triggers an "Invalid GetElementPtrInst indices for type" assert
in function checkGEPType. The fix suppresses the conversion in this case.
http://reviews.llvm.org/D20319
llvm-svn: 270479
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch turns on LoopUnrollAnalyzer by default. To mitigate compile
time regressions, I chose very conservative thresholds for now. Later we
can make them more aggressive, but it might require being smarter in
which loops we're optimizing. E.g. currently the biggest issue is that
with more agressive thresholds we unroll many cold loops, which
increases compile time for no performance benefit (performance of those
loops is improved, but it doesn't matter since they are cold).
Test results for compile time(using 4 samples to reduce noise):
```
MultiSource/Benchmarks/VersaBench/ecbdes/ecbdes 5.19%
SingleSource/Benchmarks/Polybench/medley/reg_detect/reg_detect 4.19%
MultiSource/Benchmarks/FreeBench/fourinarow/fourinarow 3.39%
MultiSource/Applications/JM/lencod/lencod 1.47%
MultiSource/Benchmarks/Fhourstones-3_1/fhourstones3_1 -6.06%
```
I didn't see any performance changes in the testsuite, but it improves
some internal tests.
Reviewers: hfinkel, chandlerc
Subscribers: llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D20482
llvm-svn: 270478
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
MBBs don't necessarily have a name (in my experience, they almost never
do), in which case this logging is quite unhelpful. The number seems to
work well.
Reviewers: iteratee
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20533
llvm-svn: 270477
|
| |
|
|
|
|
|
|
|
|
|
| |
This will pave the way to introduce a full fledged symbol visitor
similar to how we have a type visitor, thus allowing the same
dumping code to be used in llvm-readobj and llvm-pdbdump.
Differential Revision: http://reviews.llvm.org/D20384
Reviewed By: rnk
llvm-svn: 270475
|
| |
|
|
| |
llvm-svn: 270469
|
| |
|
|
| |
llvm-svn: 270467
|
| |
|
|
| |
llvm-svn: 270466
|
| |
|
|
| |
llvm-svn: 270465
|
| |
|
|
|
|
|
|
| |
Use the more specific LiveInterval::removeSegment instead of
LiveInterval::shrinkToUses when we know the specific range that's
being removed.
llvm-svn: 270463
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the string pool
Now that the string pool is referential rather than maintaining its own
copy of string data, compressed sections (well, technically only the
debug_str section*) need to be preserved for the lifetime of the pool to
match.
* I'm not currently optimizing for memory footprint with compressed
input - the major memory limit I'm hitting is on dwp+dwp merge steps
and we aren't currently compressing contents in dwp files, just in the
.dwo inputs.
llvm-svn: 270462
|
| |
|
|
| |
llvm-svn: 270459
|
| |
|
|
|
|
|
|
|
| |
In r268693, we started requiring that SelectionDAGISel::Select return
void, but provided a default implementation that did just that by
calling into the old interface. Now that all targets have been
updated, we'll just remove the default implementation.
llvm-svn: 270454
|
| |
|
|
| |
llvm-svn: 270453
|