| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent patch added support for consumeInteger() and made
getAsInteger delegate to this function. A few buildbots are
failing as a result with an assertion failure. On a hunch,
I tested what happens if I call getAsInteger() on an empty
string, and sure enough it crashes the same way that the
buildbots are crashing.
I confirmed that getAsInteger() on an empty string did not
crash before my patch, so I suspect this to be the cause.
I also added a unit test for the empty string.
llvm-svn: 282170
|
|
|
|
| |
llvm-svn: 282169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To hoist stores past loads, we used to search for potential
conflicting loads on the hoisting path by following a MemorySSA
def-def link from the store to be hoisted to the previous
defining memory access, and from there we followed the def-use
chains to all the uses that occur on the hoisting path. The
problem is that the def-def link may point to a store that does
not alias with the store to be hoisted, and so the loads that are
walked may not alias with the store to be hoisted, and even as in
the testcase of PR30216, the loads that may alias with the store
to be hoisted are not visited.
The current patch visits all loads on the path from the store to
be hoisted to the hoisting position and uses the alias analysis
to ask whether the store may alias the load. I was not able to
use the MemorySSA functionality to ask for whether load and
store are clobbered: I'm not sure which function to call, so I
used a call to AA->isNoAlias().
Store past store is still working as before using a MemorySSA
query: I added an extra test to pr30216.ll to make sure store
past store does not regress.
Differential Revision: https://reviews.llvm.org/D24517
llvm-svn: 282168
|
|
|
|
|
|
|
|
|
| |
The test exposed a bug in the StructuredData Serialization code, which did not
escape the backslash properly. This manifested itself as windows breakpoint
serialization roundtrip test not succeeding (as windows paths included
backslashes).
llvm-svn: 282167
|
|
|
|
|
|
|
| |
It doesn't matter which direction we rotate and we haven't really
started optimizing the linker script code, so keep this simple.
llvm-svn: 282166
|
|
|
|
| |
llvm-svn: 282165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringRef::getInteger() exists and treats the entire string as
an integer of the specified radix, failing if any invalid characters
are encountered or the number overflows.
Sometimes you might have something like "123456foo" and you want
to get the number 123456 and leave the string "foo" remaining.
This is similar to what would be possible by using the standard
runtime library functions strtoul et al and specifying an end
pointer.
This patch adds consumeInteger(), which does exactly that. It
consumes as much as possible until an invalid character is found,
and modifies the StringRef in place so that upon return only
the portion of the StringRef after the number remains.
Differential Revision: https://reviews.llvm.org/D24778
llvm-svn: 282164
|
|
|
|
| |
llvm-svn: 282163
|
|
|
|
| |
llvm-svn: 282161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch, GVN-hoist would think that a branch instruction is a scalar instruction
and would try to value number it. The patch filters out all such kind of irrelevant instructions.
A bit frustrating is that there is no easy way to discard all those very infrequent instructions,
a bit like isa<TerminatorInst> that stands for a large family of instructions. I'm thinking that
checking for those very infrequent other instructions would cost us more in compilation time
than just letting those instructions getting numbered, so I'm still thinking that a simpler check:
if (isa<TerminatorInst>(I))
return false;
is better than listing all the other less frequent instructions.
Differential Revision: https://reviews.llvm.org/D23929
llvm-svn: 282160
|
|
|
|
|
|
| |
Before the symbols were becoming undefined.
llvm-svn: 282159
|
|
|
|
| |
llvm-svn: 282158
|
|
|
|
|
|
|
|
| |
In ShadowToMem we call MemToShadow potentially for incorrect addresses.
So DCHECK(IsAppMem(p)) can fire in debug mode.
Fix this by swapping range and MemToShadow checks.
llvm-svn: 282157
|
|
|
|
|
|
|
|
|
| |
Summary:
The diagnostic did not handle ~ well. An expression such as ~0 is often used when 'all ones' is needed.
Differential Revision: https://reviews.llvm.org/D24232
llvm-svn: 282156
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The additional fix is:
When adding debug information to a lowered phi node in mem2reg
check that we have a valid insertion point after the phi for adding
the debug information.
This change addresses the issue in pr30468 where a lowered phi was
added before a catchswitch and no debug information should be added
after the phi in this case.
Differential Revision: https://reviews.llvm.org/D24797
llvm-svn: 282155
|
|
|
|
|
|
|
| |
Bot now complaining about -flto=thin reference, used similar workaround
for that failure.
llvm-svn: 282154
|
|
|
|
| |
llvm-svn: 282153
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fix in r282148 was not enough to fix the following error:
/home/llvmbb/llvm-build-dir/clang-sphinx-docs/llvm/src/tools/clang/docs/CommandGuide/clang.rst:338:
WARNING: unknown option: -flto=full
on the sphinx bot:
http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/16313
(not reproducible locally).
This time, simply remove the option reference.
llvm-svn: 282151
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Reviewers:
Subscribers:
llvm-svn: 282150
|
|
|
|
| |
llvm-svn: 282149
|
|
|
|
|
|
| |
/opt/llvm/build.attributes.src/tools/clang/docs/CommandGuide/clang.rst:338: WARNING: unknown option: -flto=full
llvm-svn: 282148
|
|
|
|
| |
llvm-svn: 282147
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hokein
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24803
llvm-svn: 282146
|
|
|
|
|
|
|
|
|
| |
Also added range checking for DPP attributes.
Assembler tests added as well.
Differential Revision: https://reviews.llvm.org/D24755
llvm-svn: 282145
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to:
https://reviews.llvm.org/D21409
The LXVD2X, LXVW4X, STXVD2X and STXVW4X instructions permute the two doublewords
in the vector register when in little-endian mode. Custom code ensures that the
necessary swaps are inserted for these. This patch simply removes the possibilty
that a load/store node will match one of these instructions in the SDAG as that
would not insert the necessary swaps.
llvm-svn: 282144
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch corresponds to review:
https://reviews.llvm.org/D19825
The new lxvx/stxvx instructions do not require the swaps to line the elements
up correctly. In order to select them over the lxvd2x/lxvw4x instructions which
require swaps, the patterns for the old instruction have a predicate that
ensures they won't be selected on Power9 and newer CPUs.
llvm-svn: 282143
|
|
|
|
|
|
|
|
|
| |
For mips assember '#' is the start of comment. We get assembler error messages if # is used in the struct names. Therefore using '$' which works for all architectures.
Differential: D24335
Reviewed by: zhaoqin
llvm-svn: 282142
|
|
|
|
|
|
|
|
|
| |
For MIPS '#' is the start of comment line. Therefore we get assembler errors if # is used in the structure names.
Differential: D24334
Reviewed by: zhaoqin
llvm-svn: 282141
|
|
|
|
| |
llvm-svn: 282139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before:
class X {
delete () {
...
}
}
After:
class X {
delete() {
...
}
}
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24804
llvm-svn: 282138
|
|
|
|
|
|
| |
that would properly compile to valid assembly.
llvm-svn: 282137
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When building pre-upload hooks using git-clang-format, it is useful to limit the scope to a diff of two commits (instead of from a commit against the working tree) to allow for less false positives in dependent commits.
This change adds the option of specifying two git commits to git-clang-format when using the `--diff` flag, which uses a different strategy to diff (using `git-diff-tree` instead of `git-diff-index`), and runs clang-format against the second commit instead of the working directory.
There is a slight backwards-incompatibility introduced with this change: if a filename matches a branch name or other commit-ish, then `git clang-format <commit> <file>` will no longer work as expected; use `git clang-format <commit> -- <file>` instead.
Patch by Luis Hector Chavez!
Reviewers: djasper, lodato
Subscribers: lodato, cfe-commits, srhines
Projects: #clang-c
Differential Revision: https://reviews.llvm.org/D24319
llvm-svn: 282136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When extracting options for long options (starting with `--`), the use of
`MIUtilString::SplitConsiderQuotes` to split all the arguments was being
conditioned on the option type to be expected. This was wrong as this caused
other options to be parsed incorrectly since it was not taking into account the
presence of quotes.
Patch by Ed Munoz <edmunoz@microsoft.com>
Reviewers: edmunoz, ki.stfu
Subscribers: ki.stfu, lldb-commits
Projects: #lldb
Differential Revision: https://reviews.llvm.org/D24202
llvm-svn: 282135
|
|
|
|
| |
llvm-svn: 282134
|
|
|
|
|
|
|
|
|
|
| |
VPTERNLOG is a ternary instruction with an immediate specifying the logical operation to perform. For each bit position in the 3 source vectors the bit from each source is concatenated together and the resulting 3-bit value is used to select a bit in the immediate. This bit value is written to the result vector.
We can commute this by swapping operands and modifying the immediate. To modify the immediate we need to swap two pairs of bits. The pairs correspond to the locations in the immediate where the commuted operands bits have opposite values and the uncommuted operand has the same value. Bits 0 and 7 will never be swapped since the relevant bits from all sources are the same value.
This refactors and reuses parts of the FMA3 commuting code which is also a three operand instruction.
llvm-svn: 282132
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is basically the first step toward what will
RegisterBankInfo look when it gets TableGen'ed.
It introduces a XXXGenRegisterBankInfo.def file that is what TableGen
will issue at some point. Moreover, the RegBanks field in
RegisterBankInfo changed to reflect the static (compile time) aspect of
the information.
llvm-svn: 282131
|
|
|
|
|
|
|
|
| |
When initializing an instance of OperandsMapper, instead of using
SmallVector::resize followed by std::fill, use the function that
directly does that in SmallVector.
llvm-svn: 282130
|
|
|
|
|
|
| |
> MaxSize, fix sha1 in corpus stats; various refactorings
llvm-svn: 282129
|
|
|
|
|
|
|
|
| |
The method was hard-coded to check only the 0th element of the array.
This manifested as NSLog messages behaving incorrectly on macOS.
(This is independent of the broken DarwinLog feature).
llvm-svn: 282128
|
|
|
|
| |
llvm-svn: 282127
|
|
|
|
|
|
| |
uses_allocator_v
llvm-svn: 282126
|
|
|
|
|
|
| |
Checking defined isn't good enough we also need to handle defined to empty string.
llvm-svn: 282125
|
|
|
|
|
|
|
| |
We were falling through from one case to another in a switch statement.
Oops.
llvm-svn: 282124
|
|
|
|
|
|
|
|
| |
Patch by Yacine Belkadi
Differential Revision: https://reviews.llvm.org/D12158
llvm-svn: 282123
|
|
|
|
|
|
| |
Checking if they evaluate to true cases prevents passing values that evaluate to false cases. Instead we should check if the variables are defined.
llvm-svn: 282122
|
|
|
|
| |
llvm-svn: 282121
|
|
|
|
| |
llvm-svn: 282119
|
|
|
|
|
|
| |
This should finally give a stable sorting over all implementations.
llvm-svn: 282118
|
|
|
|
| |
llvm-svn: 282117
|