| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
and also the dependent r282175 "GVN-hoist: do not dereference null pointers"
It's causing compiler crashes building Harfbuzz (PR30499).
llvm-svn: 282199
|
|
|
|
| |
llvm-svn: 282198
|
|
|
|
|
|
|
|
|
|
| |
The ELF spec doesn't allow relocations to point directly to
a deduplicated COMDAT section but this unfortunately happens in
practice. Bail out early instead of crashing.
Differential Revision: https://reviews.llvm.org/D24750
llvm-svn: 282197
|
|
|
|
|
|
|
|
| |
This code was adding an explicit dependency on libclang because lldb needs clang headers, changing this to instead depend on the clang tablegen targets means we don't have to depend on building the clang bits in libclang that lldb doesn't need.
Note this is still a bit of a hack because we're adding the dependency to all lldb libraries, instead of just the ones that need it.
llvm-svn: 282196
|
|
|
|
|
|
|
| |
It doesn't like the implicit conversion from T[] to ArrayRef<T>
so I'm using `llvm::makeArrayRef()`. Hopefully I got everything.
llvm-svn: 282195
|
|
|
|
|
|
|
| |
Use lane masks for calculating covering and aliasing of register
references.
llvm-svn: 282194
|
|
|
|
| |
llvm-svn: 282193
|
|
|
|
|
|
|
|
|
| |
USR_OVF is a subregister of USR, which is a member of CtrRegs. Having both
a register and its proper subregister in the same register class has bad
consequences for lane mask calculation: based solely on the lane mask info,
USR_OVF would not appear to be a subregister of USR.
llvm-svn: 282192
|
|
|
|
| |
llvm-svn: 282191
|
|
|
|
| |
llvm-svn: 282190
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24817
llvm-svn: 282189
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
|
|
|
|
|
| |
Reviewed-by: rafael
llvm-svn: 282187
|
|
|
|
|
|
| |
rdar://28432565
llvm-svn: 282186
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to MSDN (see the PR), functions which don't touch any callee-saved
registers (including %rsp) don't need any unwind info.
This patch makes LLVM not emit unwind info for such functions, to save
binary size.
Differential Revision: https://reviews.llvm.org/D24748
llvm-svn: 282185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like NetBSD, OpenBSD prefers having a consistent set of typedefs
across the architectures it supports over strictly following the ARM
ABIs. The diff below makes sure that clang's view of those types
matches OpenBSD's system header files. It also adds a test that
checks the relevant types on all OpenBSD platforms that clang works
on. Hopefully we can add mips64 and powerpc to that list in the
future.
Patch by Mark Kettenis <mark.kettenis@xs4all.nl>
llvm-svn: 282184
|
|
|
|
| |
llvm-svn: 282183
|
|
|
|
|
|
|
|
| |
Atomic comparison instructions use the sub-word load instruction on
Power8 and up but the value is not sign extended prior to the signed word
compare instruction. This patch adds that sign extension.
llvm-svn: 282182
|
|
|
|
|
|
| |
Should fix the windows bots.
llvm-svn: 282181
|
|
|
|
|
|
| |
This fixes a case where we would produce an unaligned PT_LOAD.
llvm-svn: 282180
|
|
|
|
|
|
| |
elsewhere too
llvm-svn: 282179
|
|
|
|
| |
llvm-svn: 282178
|
|
|
|
|
|
|
|
|
|
|
|
| |
Correctly use alignment size from loaded size not output value size.
Reviewers: jyknight, tstellarAMD, arsenm
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23356
llvm-svn: 282177
|
|
|
|
|
|
|
| |
With the recent changes there should always be a 1:1 correspondence in
the correct order between OutputSections and OutputSectionCommands.
llvm-svn: 282176
|
|
|
|
|
|
|
| |
there may be basic blocks without memory accesses, in which case the
list of accesses is a null pointer.
llvm-svn: 282175
|
|
|
|
|
|
|
|
|
|
|
| |
Follow-up to r280705: Make sure that the SP is only restored after all data
is loaded from the stack frame, if there is no red zone.
This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519.
Differential Revision: https://reviews.llvm.org/D24466
llvm-svn: 282174
|
|
|
|
|
|
|
| |
This also fixes the linker script accounting for the ELF header in
some places but not in others.
llvm-svn: 282173
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started failing recently:
TestDarwinLogSourceDebug.py
It looks like the behavior of specifying the OS_ACTIVITY_MODE
env var with no value used to work for no-info/no-debug content.
That doesn't appear to be the case now. Switch to specifying
the proper value ('default') when no info-level and no debug-level
content is expected.
llvm-svn: 282172
|
|
|
|
|
|
|
|
| |
Also fixed up a couple misbehaving functions. It is perfectly
legal to have env vars with no values (i.e. the '=' and following
need not be present).
llvm-svn: 282171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|