| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 304372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: LiveRangeShrink pass moves instruction right after the definition with the same BB if the instruction and its operands all have more than one use. This pass is inexpensive and guarantees optimal live-range within BB.
Reviewers: davidxl, wmi, hfinkel, MatzeB, andreadb
Reviewed By: MatzeB, andreadb
Subscribers: hiraditya, jyknight, sanjoy, skatkov, gberry, jholewinski, qcolombet, javed.absar, krytarowski, atrick, spatel, RKSimon, andreadb, MatzeB, mehdi_amini, mgorny, efriedma, davide, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32563
llvm-svn: 304371
|
| |
|
|
| |
llvm-svn: 304370
|
| |
|
|
|
|
|
| |
The sections are ordered, so we can just use the first one when
looking for the lowest address.
llvm-svn: 304369
|
| |
|
|
| |
llvm-svn: 304368
|
| |
|
|
|
|
|
|
|
| |
These are no-ops when there are no invokes. We don't need to emit LSDAs
for them.
Fixes PR33220.
llvm-svn: 304367
|
| |
|
|
|
|
|
| |
The values are marked as livein in the successor blocks so marking them
as killed or dead was wrong.
llvm-svn: 304366
|
| |
|
|
| |
llvm-svn: 304365
|
| |
|
|
| |
llvm-svn: 304364
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We should have a single call site entry with no landing pad. This
indicates that no EH action should be taken and the unwinder should
unwind to the next frame.
We currently don't recognize __gxx_personality_seh0 as a known
personality, so we forcibly emit a table, and that table was wrong. This
was filed as PR33220. Now we emit a correct table for that personality.
The next step is to recognize that we can completely skip the table for
this personality.
llvm-svn: 304363
|
| |
|
|
|
|
|
| |
BIND_OPCODE_SET_DYLIB_SPECIAL_IMM(0) is a valid way to setp library
ordinal. MachOObject should set LibraryOrdinalSet even when IMM is zero.
llvm-svn: 304362
|
| |
|
|
| |
llvm-svn: 304361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch corrects the build errors I encountered when building on MinGW64.
Reviewers: mati865, rnk, compnerd, smeenai, bcraig
Reviewed By: mati865, smeenai
Subscribers: martell, chapuni, cfe-commits
Differential Revision: https://reviews.llvm.org/D33082
llvm-svn: 304360
|
| |
|
|
|
|
|
|
|
| |
As per r241993, libunwind_ext.h is not used anymore, and thus only the public libunwind includes are needed.
This eases distro packaging efforts and removes an unneeded requirement for out-of-tree building.
Reviewed as D33178
llvm-svn: 304359
|
| |
|
|
| |
llvm-svn: 304358
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
|
| |
|
|
| |
llvm-svn: 304356
|
| |
|
|
| |
llvm-svn: 304355
|
| |
|
|
| |
llvm-svn: 304354
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The intent of the test is to check that array lengths greater than
UINT_MAX work properly. Change the test to stress that scenario, without
triggering pointer overflow UB.
Caught by a WIP pointer overflow checker in clang.
Differential Revision: https://reviews.llvm.org/D33149
llvm-svn: 304353
|
| |
|
|
| |
llvm-svn: 304352
|
| |
|
|
|
|
|
|
|
| |
The shell test versions didn't get all of the flags normal tests
do, specifically warning flags. This patch makes them .pass.cpp tests,
and uses a lit.local.cfg to add -fcoroutines-ts and to make them
UNSUPPORTED when that flag isn't available.
llvm-svn: 304351
|
| |
|
|
|
|
| |
investigating.
llvm-svn: 304350
|
| |
|
|
|
|
|
|
| |
It seems not all of our bots have a std::vector::erase() taking a
const_iterator (even though that seems to be part of C++11) attempt to
workaround.
llvm-svn: 304349
|
| |
|
|
| |
llvm-svn: 304348
|
| |
|
|
|
|
| |
instead of a std::string.
llvm-svn: 304347
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to the original module map.
Also use the path and name of the original module map when emitting that
information into the .pcm file. The upshot of this is that the produced .pcm
file will track information for headers in their original locations (where the
module was preprocessed), not relative to whatever directory the preprocessed
module map was in when it was built.
llvm-svn: 304346
|
| |
|
|
|
|
|
|
|
| |
These are already wired up to work in the MSVC toolchain header search
code. However, they were unreachable from clang-cl. A user attempted to
use them in https://bugs.llvm.org/show_bug.cgi?id=33205, so let's expose
them.
llvm-svn: 304345
|
| |
|
|
|
|
|
|
|
|
|
|
| |
With these settings, the create_hwloc_map() method was being called causing an
assert(). After some consideration, it was determined that disabling affinity
explicitly should just disable hwloc as well. i.e., KMP_AFFINITY overrides
KMP_TOPOLOGY_METHOD. This lets the user know that the Hwloc mechanism is being
ignored when KMP_AFFINITY=disabled.
Differential Revision: https://reviews.llvm.org/D33208
llvm-svn: 304344
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change checks if the initial affinity mask is equal to exactly one
Windows processor group's affinity mask. If it is, then the code does not
respect the initial affinity mask and uses the entire machine instead.
The reasoning behind this is that, by default, Windows assigns exactly one
processor group as the initial affinity mask even when there are multiple
Windows processor groups available. User's typically want to use the whole
machine, so we ignore this special case and use the entire machine.
If the initial affinity mask is a proper subset of one group, or spans multiple
groups, then the initial affinity mask is respected since we can assume that the
operating system did not assign this initial affinity mask. This change only
affects machines with multiple processor groups
Differential Revision: https://reviews.llvm.org/D33210
llvm-svn: 304343
|
| |
|
|
|
|
|
|
|
|
|
|
| |
After transforming FP to ST registers:
- Do not add the ST register to the livein lists, they are reserved so
we do not need to track their liveness.
- Remove the FP registers from the livein lists, they don't have defs or
uses anymore and so are not live.
- (The setKillFlags() call is moved to an earlier place as it relies on
the FP registers still being present in the livein list.)
llvm-svn: 304342
|
| |
|
|
| |
llvm-svn: 304341
|
| |
|
|
|
|
| |
statement may fall through. NFC.
llvm-svn: 304340
|
| |
|
|
|
|
|
| |
Another step into merging the linker script and non linker script code
paths.
llvm-svn: 304339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before InputSectionBase had an OutputSection pointer, but that was not
always valid. For example, if it was a merge section one actually had
to look at MergeSec->OutSec.
This was brittle and caused bugs like the one fixed by r304260.
We now have a single Parent pointer that points to an OutputSection
for InputSection, but to a SyntheticSection for merge sections and
.eh_frame. This makes it impossible to accidentally access an invalid
OutSec.
llvm-svn: 304338
|
| |
|
|
| |
llvm-svn: 304337
|
| |
|
|
| |
llvm-svn: 304336
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Credit goes to Gor Nishanov for putting together the fix in
https://reviews.llvm.org/D33733!
This patch is essentially me patching it locally and writing some test
cases to convince myself that it was necessary for GNU statement
expressions with branches as well as coroutines. I'll ask Gor to land
his patch with just the coroutines test.
During LValue expression evaluation, references can be bound to
anything, really: call results, aggregate temporaries, local variables,
global variables, or indirect arguments. We really only want to spill
instructions that were emitted as part of expression evaluation, and
static allocas are not that.
llvm-svn: 304335
|
| |
|
|
| |
llvm-svn: 304334
|
| |
|
|
| |
llvm-svn: 304333
|
| |
|
|
| |
llvm-svn: 304332
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: @rsmith Is there a better place to put this test?
Reviewers: GorNishanov, rsmith
Reviewed By: GorNishanov
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D33660
llvm-svn: 304331
|
| |
|
|
| |
llvm-svn: 304330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fairly straightforward patch to fill in some of the holes in the
attributes API with respect to accessing parameter/argument attributes.
The patch aims to step further towards encapsulating the
idx+FirstArgIndex pattern to access these attributes to within the
AttributeList.
Patch by Daniel Neilson!
Reviewers: rnk, chandlerc, pete, javed.absar, reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33355
llvm-svn: 304329
|
| |
|
|
| |
llvm-svn: 304328
|
| |
|
|
|
|
|
|
| |
We would crash if a SHF_LINK_ORDER section pointed to a non
InputSection section. Since those sections are not merged in order,
SHF_LINK_ORDER is pretty meaningless and we can error on that case.
llvm-svn: 304327
|
| |
|
|
|
|
|
|
|
|
| |
getValueAsListOfStrings returning StringRef instead of std::string
This is the clang version of D33710.
Differential Revision: https://reviews.llvm.org/D33711
llvm-svn: 304326
|
| |
|
|
|
|
|
|
|
|
|
|
| |
StringRefs instead of std::string
Internally both these methods just return the result of getValue on either a StringInit or a CodeInit object. In both cases this returns a StringRef pointing to a string allocated in the BumpPtrAllocator so its not going anywhere. So we can just pass that StringRef along.
This is a fairly naive patch that targets just the build failures caused by this change. There's additional work that can be done to avoid creating std::string at call sites that still think getValueAsString returns a std::string. I'll try to clean those up in future patches.
Differential Revision: https://reviews.llvm.org/D33710
llvm-svn: 304325
|
| |
|
|
|
|
| |
with X86.
llvm-svn: 304324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Don't assign values to undefined references, simply don't emit those
reference edges as they are not useful (we were already not emitting
call edges to undefined refs).
Also, streamline the later lookup of value ids when writing the
summaries, by combining the check for value id existence with the access
of that value id.
Reviewers: pcc
Subscribers: Prazek, llvm-commits, inglorion
Differential Revision: https://reviews.llvm.org/D33634
llvm-svn: 304323
|