| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 276607
|
| |
|
|
|
|
|
| |
Paths like C:/foo will never work on UNIX platforms, don't bother
implicitly adding them to the search path.
llvm-svn: 276606
|
| |
|
|
| |
llvm-svn: 276605
|
| |
|
|
|
|
| |
Truncates can completely cancel out a zext or sext instruction.
llvm-svn: 276604
|
| |
|
|
|
|
|
| |
I think I've solved issues with is_assignable and references to incomplete
types. The updated patch adds tests for this case.
llvm-svn: 276603
|
| |
|
|
|
|
|
| |
We can combine metadata from multiple instructions intelligently for
certain metadata nodes.
llvm-svn: 276602
|
| |
|
|
|
|
|
|
|
| |
If we two loads of two different alignments, we must use the minimum of
the two alignments when hoisting. Same deal for stores.
For allocas, use the maximum of the two allocas.
llvm-svn: 276601
|
| |
|
|
|
|
| |
Use a range-based for loop, no functional change is intended.
llvm-svn: 276600
|
| |
|
|
| |
llvm-svn: 276599
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
|
| |
|
|
| |
llvm-svn: 276597
|
| |
|
|
| |
llvm-svn: 276596
|
| |
|
|
| |
llvm-svn: 276595
|
| |
|
|
|
|
|
|
| |
In C++03 mode evaluating the SFINAE can cause a hard error due to
access control violations. This is a problem because the SFINAE
is evaluated as soon as the class is instantiated, and not later.
llvm-svn: 276594
|
| |
|
|
| |
llvm-svn: 276593
|
| |
|
|
|
|
|
|
|
|
| |
PROVIDE request us to define a symbol only if it is referenced and is
not defined by any object included in the link. We created the
symbol in the symbol table no matter what.
Differential Revision: https://reviews.llvm.org/D22739
llvm-svn: 276592
|
| |
|
|
|
|
| |
STL@microsoft.com
llvm-svn: 276591
|
| |
|
|
|
|
| |
See D21820 for more information (https://reviews.llvm.org/D21820).
llvm-svn: 276590
|
| |
|
|
| |
llvm-svn: 276589
|
| |
|
|
| |
llvm-svn: 276588
|
| |
|
|
| |
llvm-svn: 276587
|
| |
|
|
| |
llvm-svn: 276586
|
| |
|
|
| |
llvm-svn: 276585
|
| |
|
|
| |
llvm-svn: 276584
|
| |
|
|
| |
llvm-svn: 276583
|
| |
|
|
| |
llvm-svn: 276582
|
| |
|
|
| |
llvm-svn: 276581
|
| |
|
|
|
|
| |
STL@microsoft.com
llvm-svn: 276580
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D22738
llvm-svn: 276579
|
| |
|
|
| |
llvm-svn: 276578
|
| |
|
|
|
|
|
|
|
| |
I'm told that some optimizers like lambdas a lot more than mem_fn.
Given that the readability difference is basically nil, and we seem to
use lambdas basically everywhere else, it seems sensible to just use
lambdas.
llvm-svn: 276577
|
| |
|
|
|
|
| |
STL@microsoft.com
llvm-svn: 276576
|
| |
|
|
| |
llvm-svn: 276575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we handled an expression as a vector of tokens. In other
words, an expression was a vector of uncooked raw StringRefs.
When we need a value of an expression, we used ExprParser to run
the expression.
The separation was needed essentially because parse time is too
early to evaluate an expression. In order to evaluate an expression,
we need to finalize section sizes. Because linker script parsing
is done at very early stage of the linking process, we can't
evaluate expressions while parsing.
The above mechanism worked fairly well, but there were a few
drawbacks.
One thing is that we sometimes have to parse the same expression
more than once in order to find the end of the expression.
In some contexts, linker script expressions have no clear end marker.
So, we needed to recognize balanced expressions and ternary operators.
The other is poor error reporting. Since expressions are parsed
basically twice, and some information that is available at the first
stage is lost in the second stage, it was hard to print out
apprpriate error messages.
This patch fixes the issues with a new approach.
Now the expression parsing is integrated into ScriptParser.
ExprParser class is removed. Expressions are represented as lambdas
instead of vectors of tokens. Lambdas captures information they
need to run themselves when they are created.
In this way, ends of expressions are naturally detected, and
errors are handled in the usual way. This patch also reduces
the amount of code.
Differential Revision: https://reviews.llvm.org/D22728
llvm-svn: 276574
|
| |
|
|
|
|
| |
No functional change is intended.
llvm-svn: 276573
|
| |
|
|
|
|
|
|
|
|
| |
Process::GetEnv does the right thing across our platforms.
CommandLine.cpp had, more or less, the same logic. Let's remove the
duplication.
No functional change is intended.
llvm-svn: 276572
|
| |
|
|
| |
llvm-svn: 276571
|
| |
|
|
| |
llvm-svn: 276570
|
| |
|
|
|
|
| |
As with all AMD CPUs, excavator has poor SHLD/SHRD performance. Also added bdver3 to the test as it was missing.
llvm-svn: 276569
|
| |
|
|
| |
llvm-svn: 276568
|
| |
|
|
| |
llvm-svn: 276567
|
| |
|
|
| |
llvm-svn: 276566
|
| |
|
|
| |
llvm-svn: 276565
|
| |
|
|
|
|
| |
Thanks to Simon Pilgrim for catching the mistake.
llvm-svn: 276564
|
| |
|
|
|
|
| |
demonstrate PR23941
llvm-svn: 276563
|
| |
|
|
|
|
|
|
| |
encoded versions.
This places the 132/213/231 form number in front of the SS/SD/PS/PD. Move the Y for 256-bit versions to be after the PS/PD. Change the AVX512 scalar forms to include a Z in the their name. This new format should be consistent with the general naming of instructions.
llvm-svn: 276559
|
| |
|
|
| |
llvm-svn: 276558
|
| |
|
|
|
|
|
|
|
|
| |
Remove some FIXMEs in the surrounding code,
which have been addressed long time ago
by introducing checker-specific tags.
Differential Revision: https://reviews.llvm.org/D22622
llvm-svn: 276557
|
| |
|
|
| |
llvm-svn: 276556
|
| |
|
|
|
|
| |
the operand types exactly match the normal VPSRAVW/D/Q instructions.
llvm-svn: 276555
|