| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The reasoning behind this change is explained in D33454, which unfortunately
broke the Windows version (due to the platform not supporting partial unmapping
of a memory region).
This new approach changes `MmapAlignedOrDie` to allow for the specification of
a `padding_chunk`. If non-null, and the initial allocation is aligned, this
padding chunk will hold the address of the extra memory (of `alignment` bytes).
This allows `AllocateRegion` to get 2 regions if the memory is aligned
properly, and thus help reduce fragmentation (and saves on unmapping
operations). As with the initial D33454, we use a stash in the 32-bit Primary
to hold those extra regions and return them on the fast-path.
The Windows version of `MmapAlignedOrDie` will always return a 0
`padding_chunk` if one was requested.
Reviewers: alekseyshl, dvyukov, kcc
Reviewed By: alekseyshl
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D34152
llvm-svn: 305391
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3a204faa093c681a1e96c5e0622f50649b761ee0.
I've upset a buildbot which runs the address sanitizer:
ERROR: AddressSanitizer: stack-use-after-scope
lib/Target/ARM/ARMISelLowering.cpp:2690
That Twine variable is used illegally.
llvm-svn: 305390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For multiprecision arithmetic on MIPS, rather than using ISD::ADDE / ISD::ADDC,
get SelectionDAG to break down the operation into ISD::ADDs and ISD::SETCCs.
For MIPS, only the DSP ASE has a carry flag, so in the general case it is not
useful to directly support ISD::{ADDE, ADDC, SUBE, SUBC} nodes.
Also improve the generation code in such cases for targets with
TargetLoweringBase::ZeroOrOneBooleanContent by directly using the result of the
comparison node rather than using it in selects. Similarly for ISD::SUBE /
ISD::SUBC.
Address optimization breakage by moving the generation of MIPS specific integer
multiply-accumulate nodes to before legalization.
This revolves PR32713 and PR33424.
Thanks to Simonas Kazlauskas and Pirama Arumuga Nainar for reporting the issue!
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D33494
llvm-svn: 305389
|
| |
|
|
| |
llvm-svn: 305388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARM backend asserts against constant pool lowering when it generates
execute-only code in order to prevent the generation of constant pools in
the text section. It appears that target independent optimizations might
generate DAG nodes that represent constant pools. By lowering such nodes
as global addresses we don't violate the semantics of execute-only code
and also it is guaranteed that execute-only behaves correct with the
position-independent addressing modes that support execute-only code.
Differential Revision: https://reviews.llvm.org/D33773
llvm-svn: 305387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: fhahn, javed.absar, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D33894
llvm-svn: 305386
|
| |
|
|
| |
llvm-svn: 305385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
|
| |
|
|
|
|
|
|
| |
The step count depends on code generated by compiler (GCC/Clang).
It will also vary for different MIPS arch variant. Hence skipping these test for MIPS.
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two systemic machine verifier errors in the long
branch pass. The first is the incorrect basic block successors
and the second was the incorrect construction of several jump
instructions.
This partially resolves PR27458 and the associated PR32146.
Reviewers: slthakur
Differential Revision: https://reviews.llvm.org/D33378
llvm-svn: 305382
|
| |
|
|
|
|
| |
It broke clang-x86_64-linux-selfhost-modules-2 and some other buildbots.
llvm-svn: 305381
|
| |
|
|
|
|
|
| |
bugnumber=llvm.org/pr33452
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305380
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While a function body is being parsed, the function declaration is not considered
as a definition because it does not have a body yet. In some cases it leads to
incorrect interpretation, the case is presented in
https://bugs.llvm.org/show_bug.cgi?id=14785:
```
template<typename T> struct Somewhat {
void internal() const {}
friend void operator+(int const &, Somewhat<T> const &) {}
};
void operator+(int const &, Somewhat<char> const &x) { x.internal(); }
```
When statement `x.internal()` in the body of global `operator+` is parsed, the type
of `x` must be completed, so the instantiation of `Somewhat<char>` is started. It
instantiates the declaration of `operator+` defined inline, and makes a check for
redefinition. The check does not detect another definition because the declaration
of `operator+` is still not defining as does not have a body yet.
To solves this problem the function `isThisDeclarationADefinition` considers
a function declaration as a definition if it has flag `WillHaveBody` set.
This change fixes PR14785.
Differential Revision: https://reviews.llvm.org/D30375
llvm-svn: 305379
|
| |
|
|
|
|
|
|
|
| |
Clang does not accept regparm attribute on these platforms.
Fortunately, the default calling convention passes arguments
in registers any way
Subscribers: jaydeep, bhushan, lldb-commits, slthakur
llvm-svn: 305378
|
| |
|
|
|
|
|
|
| |
Patch by Serge Preis
Differential Revision: https://reviews.llvm.org/D32428
llvm-svn: 305377
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D34151
llvm-svn: 305376
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D34140
llvm-svn: 305375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I found that getString defined in the LLD's Driver.cpp is
exactly the same as Arg::getLastArgValue defined in
llvm/Option/ArgLIst.h. This patch removes that local function and use
the function that the Arg class provides.
Reviewers: ruiu
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D34196
llvm-svn: 305374
|
| |
|
|
| |
llvm-svn: 305373
|
| |
|
|
|
|
| |
Reverting this until a test case can be provided to aid the investigation.
llvm-svn: 305372
|
| |
|
|
|
|
|
|
| |
This is causing failures on linux bots with an invalid stream
read. It doesn't repro in any configuration on Windows, so
reverting until I have a chance to investigate on Linux.
llvm-svn: 305371
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is used to constrain `variant`'s converting constructor correctly.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D34111
llvm-svn: 305370
|
| |
|
|
| |
llvm-svn: 305369
|
| |
|
|
| |
llvm-svn: 305368
|
| |
|
|
| |
llvm-svn: 305367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to use yaml2obj and obj2yaml to round-trip CodeView
symbol and type information without having to manually specify the bytes
of the section. This makes for much easier to maintain tests. See the
tests under lld/COFF in this patch for example. Before they just said
SectionData: <blob> whereas now we can use meaningful record
descriptions. Note that it still supports the SectionData yaml field,
which could be useful for initializing a section to invalid bytes for
testing, for example.
Differential Revision: https://reviews.llvm.org/D34127
llvm-svn: 305366
|
| |
|
|
| |
llvm-svn: 305365
|
| |
|
|
|
|
|
|
| |
Summary: Pointed out by Yuka Takahashi.
Differential Revision: https://reviews.llvm.org/D34192
llvm-svn: 305364
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently we build the co_await expressions on the wrong implicit statements of the implicit ranged for; Specifically we build the co_await expression wrapping the range declaration, but it should wrap the begin expression.
This patch fixes co_await on range for.
Reviewers: rsmith, GorNishanov
Reviewed By: GorNishanov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D34021
llvm-svn: 305363
|
| |
|
|
| |
llvm-svn: 305362
|
| |
|
|
| |
llvm-svn: 305361
|
| |
|
|
| |
llvm-svn: 305360
|
| |
|
|
|
|
|
|
| |
I have confirmed that these are no longer needed with MSVC 2015.
Differential Revision: https://reviews.llvm.org/D34187
llvm-svn: 305347
|
| |
|
|
|
|
| |
currently)
llvm-svn: 305346
|
| |
|
|
|
|
|
|
|
|
| |
Summary: just flip them on.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34186
llvm-svn: 305345
|
| |
|
|
|
|
|
|
|
|
|
| |
llvm-dwarfdump output.
This patch adds code which verifies that each bucket in the .apple_names
accelerator table is either empty or has a valid hash index.
Differential Revision: https://reviews.llvm.org/D34177
llvm-svn: 305344
|
| |
|
|
| |
llvm-svn: 305343
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move the OOM decision based on RSS limits out of generic allocator to
ASan allocator, where it makes more sense at the moment.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D34180
llvm-svn: 305342
|
| |
|
|
| |
llvm-svn: 305341
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When legalizing G_LOAD/G_STORE using NarrowScalar, we should avoid emitting
%0 = G_CONSTANT ty 0
%1 = G_GEP %x, %0
since it's cheaper to not emit the redundant instructions than it is to fold them
away later.
Reviewers: qcolombet, t.p.northover, ab, rovka, aditya_nandakumar, kristof.beyls
Reviewed By: qcolombet
Subscribers: javed.absar, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D32746
llvm-svn: 305340
|
| |
|
|
| |
llvm-svn: 305339
|
| |
|
|
|
|
|
|
| |
eq (and X, C1), 0), Y, (or Y, C2)) when the icmp portion gets turned into a truncate and a signed compare with 0.
InstCombine has an optimization that recognizes an and with the sign bit of legal type size and turns it into a truncate and compare that checks the sign bit. But the select handling code doesn't recognize this idiom.
llvm-svn: 305338
|
| |
|
|
|
|
|
| |
This is similar to what we do for InputSections and makes them easier
to access.
llvm-svn: 305337
|
| |
|
|
| |
llvm-svn: 305336
|
| |
|
|
| |
llvm-svn: 305335
|
| |
|
|
| |
llvm-svn: 305334
|
| |
|
|
| |
llvm-svn: 305333
|
| |
|
|
| |
llvm-svn: 305332
|
| |
|
|
|
|
| |
libFuzzer. This is not fully functional yet, but simple tests work
llvm-svn: 305331
|
| |
|
|
|
|
|
|
| |
If pthread_attr_getstack tell us the stack is 2G, why would we doubt that?
Differential Revision: https://reviews.llvm.org/D34169
llvm-svn: 305330
|