| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 306199
|
|
|
|
|
|
|
| |
This should *really* be a llvm-mc test, but the parser is broken.
See PR33579 for the parser bug.
llvm-svn: 306198
|
|
|
|
|
|
| |
work email.
llvm-svn: 306197
|
|
|
|
| |
llvm-svn: 306196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
InstCombine replaces large allocas with small globals consts causing buffer overflows
on valid code, see PR33372.
This fix permits this optimization only if the global is dereference for alloca size.
Fixes PR33372
Reviewers: eugenis, majnemer, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34311
llvm-svn: 306194
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Used by D34311 and D34467
Reviewers: hfinkel, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34585
llvm-svn: 306193
|
|
|
|
|
|
| |
constants
llvm-svn: 306192
|
|
|
|
| |
llvm-svn: 306190
|
|
|
|
| |
llvm-svn: 306189
|
|
|
|
| |
llvm-svn: 306188
|
|
|
|
| |
llvm-svn: 306182
|
|
|
|
| |
llvm-svn: 306179
|
|
|
|
| |
llvm-svn: 306178
|
|
|
|
|
|
|
|
|
|
|
|
| |
processFixupValue is called on every relaxation iteration. applyFixup
is only called once at the very end. applyFixup is then the correct
place to do last minute changes and value checks.
While here, do proper range checks again for fixup_arm_thumb_bl. We
used to do it, but dropped because of thumb2. We now do it again, but
use the thumb2 range.
llvm-svn: 306177
|
|
|
|
|
|
|
|
|
| |
Revert "[ORC] Remove redundant semicolons from DEFINE_SIMPLE_CONVERSION_FUNCTIONS uses."
Revert "[ORC] Move ORC IR layer interface from addModuleSet to addModule and fix the module type as std::shared_ptr<Module>."
They broke ExecutionEngine/OrcMCJIT/test-global-ctors.ll on linux.
llvm-svn: 306176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After fixing (r306173) a failing test in the lld test suite (r306173),
reland r306095.
Original commit message:
[mips] Fix register positions in the aui/daui instructions
Swapped the position of the rt and rs register in the aui/daui
instructions for mips32r6 and mips64r6. With this change, the format of
the generated instructions complies with specifications and GCC.
Patch by Milos Stojanovic.
llvm-svn: 306174
|
|
|
|
|
|
|
|
| |
We would return an error in getVaPtr if the RVA table being dumped was
the last data in the .rdata section. Avoid the issue by subtracting one
from the offset and adding it back to get an open interval again.
llvm-svn: 306171
|
|
|
|
|
|
| |
regexes. NFC.
llvm-svn: 306170
|
|
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 306169
|
|
|
|
| |
llvm-svn: 306168
|
|
|
|
| |
llvm-svn: 306167
|
|
|
|
|
|
| |
module type as std::shared_ptr<Module>.
llvm-svn: 306166
|
|
|
|
|
|
|
|
|
| |
This reverts commit r306157.
It caused some timeouts in clang tests. Perhaps unreachable loops have
far too many phi nodes.
Reverting and investigating.
llvm-svn: 306162
|
|
|
|
| |
llvm-svn: 306160
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without this patch some types have incorrect size and/or alignment
according to the MSP430 EABI.
Reviewers: asl, awygle
Reviewed By: asl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34561
llvm-svn: 306159
|
|
|
|
| |
llvm-svn: 306158
|
|
|
|
|
|
|
|
|
|
| |
Currently, the implementation of delete dead loops has a special case
when the loop being deleted is never executed. This special case
(updating of exit block's incoming values for phis) can be
run as a prepass for non-executable loops before performing
the actual deletion.
llvm-svn: 306157
|
|
|
|
|
|
| |
compare with the expected value rather than counting bits. NFCI
llvm-svn: 306155
|
|
|
|
|
|
|
|
| |
in isAllOnesValue, isMaxSigendValue, and isMinSignedValue. NFCI
The trailing bit methods will early out if they find a bit of the opposite while popcount must always look at all bits. I also assume that more CPUs implement trailing bit counting with native instructions than population count.
llvm-svn: 306154
|
|
|
|
|
|
| |
countLeadingOnes inline for consistency with countTrailingOnes and countLeadingZeros. NFCI
llvm-svn: 306153
|
|
|
|
| |
llvm-svn: 306152
|
|
|
|
|
|
| |
reverse order. This is no longer being done after r298791. NFC
llvm-svn: 306151
|
|
|
|
|
|
|
|
| |
This is useful when you want to look at a specific chunk of a
stream or look for discontinuities, and you need to know the
list of blocks occupied by a stream.
llvm-svn: 306150
|
|
|
|
|
|
|
|
| |
This patch dumps the raw bytes of the pdb name map which contains
the mapping of stream name to stream index for the string table
and other reserved streams.
llvm-svn: 306148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
opt-stats.py and opt-viewer.py's argument parsers both take a positional
argument 'yaml_files'. Positional arguments in Python's argparse module are
required by default, so the subsequent checks for `len(args.yaml_files) == 0`
are unnecessary -- if the length was zero, then the call to
`parser.parse_args()` would have thrown an error already.
Because there is no way for `len(args.yaml_files)` to be zero at these
points, removing the code is NFC.
Reviewers: anemet, davidxl
Reviewed By: anemet
Subscribers: llvm-commits, fhahn
Differential Revision: https://reviews.llvm.org/D34567
llvm-svn: 306147
|
|
|
|
|
|
|
|
|
|
| |
Normally we can only make sense of the content of a PDB in terms
of streams and blocks, but in some cases it may be useful to dump
bytes at a specific absolute file offset. For example, if you
know that some interesting data is at a particular location and
you want to see some surrounding data.
llvm-svn: 306146
|
|
|
|
|
|
| |
This breaks passing of aligned function arguments.
llvm-svn: 306145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains a pass that transforms CBZ/CBNZ/TBZ/TBNZ instructions into a
conditional branch (Bcc), when the NZCV flags can be set for "free". This is
preferred on targets that have more flexibility when scheduling Bcc
instructions as compared to CBZ/CBNZ/TBZ/TBNZ (assuming all other variables are
equal). This can reduce register pressure and is also the default behavior for
GCC.
A few examples:
add w8, w0, w1 -> cmn w0, w1 ; CMN is an alias of ADDS.
cbz w8, .LBB_2 -> b.eq .LBB0_2 ; single def/use of w8 removed.
add w8, w0, w1 -> adds w8, w0, w1 ; w8 has multiple uses.
cbz w8, .LBB1_2 -> b.eq .LBB1_2
sub w8, w0, w1 -> subs w8, w0, w1 ; w8 has multiple uses.
tbz w8, #31, .LBB6_2 -> b.ge .LBB6_2
In looking at all current sub-target machine descriptions, this transformation
appears to be either positive or neutral.
Differential Revision: https://reviews.llvm.org/D34220.
llvm-svn: 306144
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit r306010 adjusted the condition as follows:
- if (Is64Bit) {
+ if (!STI.isTargetWin32()) {
The intent was to preserve the behavior on all Windows platforms
but extend the behavior on 64-bit Windows platforms to every
other one. (Before r306010, emitStackProbeCall only ever executed
when emitting code for Windows triples.)
Unfortunately,
if (Is64Bit && STI.isOSWindows())
is not the same as
if (!STI.isTargetWin32())
because of the way isTargetWin32() is defined:
bool isTargetWin32() const {
return !In64BitMode && (isTargetCygMing() ||
isTargetKnownWindowsMSVC());
}
In practice this broke the JIT tests on 32-bit Windows, which did not
satisfy the new condition:
LLVM :: ExecutionEngine/MCJIT/2003-01-15-AlignmentTest.ll
LLVM :: ExecutionEngine/MCJIT/2003-08-15-AllocaAssertion.ll
LLVM :: ExecutionEngine/MCJIT/2003-08-23-RegisterAllocatePhysReg.ll
LLVM :: ExecutionEngine/MCJIT/test-loadstore.ll
LLVM :: ExecutionEngine/OrcMCJIT/2003-01-15-AlignmentTest.ll
LLVM :: ExecutionEngine/OrcMCJIT/2003-08-15-AllocaAssertion.ll
LLVM :: ExecutionEngine/OrcMCJIT/2003-08-23-RegisterAllocatePhysReg.ll
LLVM :: ExecutionEngine/OrcMCJIT/test-loadstore.ll
because %esp was not updated correctly. The failures are only visible
on a MSVC 2017 Debug build, for which we do not have bots.
llvm-svn: 306142
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal here is to make it possible to display absolute
file offsets when dumping byets from an MSF. The problem is
that when dumping bytes from an MSF, often the bytes will
cross a block boundary and encounter a discontinuity. We
can't use the normal formatBinary() function for this because
this would just treat the sequence as entirely ascending, and
not account out-of-order blocks.
This patch adds a formatMsfData() function to our printer, and
then uses this function to improve the output of the -stream-data
command line option for dumping bytes from a particular stream.
Test coverage is also expanded to make sure to include all possible
scenarios of offsets, sizes, and crossing block boundaries.
llvm-svn: 306141
|
|
|
|
|
|
|
| |
It causes an extra pass of the machine verifier to be added to the pass
manager, and causes test/CodeGen/Generic/llc-start-stop.ll to fail.
llvm-svn: 306140
|
|
|
|
|
|
|
|
|
|
|
| |
I'm not sure yet why this wouldn't fail in the simple case,
but clearly I used the wrong value type with:
https://reviews.llvm.org/rL306040
...and the bug manifests with:
https://bugs.llvm.org/show_bug.cgi?id=33560
llvm-svn: 306139
|
|
|
|
|
|
| |
Check on slow/fast unaligned memory targets
llvm-svn: 306138
|
|
|
|
| |
llvm-svn: 306133
|
|
|
|
| |
llvm-svn: 306131
|
|
|
|
| |
llvm-svn: 306130
|
|
|
|
| |
llvm-svn: 306129
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.
One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.
Differential Revision: https://reviews.llvm.org/D34547
llvm-svn: 306126
|
|
|
|
| |
llvm-svn: 306124
|
|
|
|
|
|
|
|
|
| |
This is essentially just a BinaryStreamRef packaged with an
offset and the logic for reading one is no different than the
logic for reading a BinaryStreamRef, except that we save the
current offset.
llvm-svn: 306122
|