| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When constructing global address literals while targeting the RWPI
relocation model. LLVM currently only uses literal pools. If MOVW/MOVT
instructions are available we can use these instead. Beside being more
efficient it allows -arm-execute-only to work with
-relocation-model=RWPI as well.
When we generate MOVW/MOVT for global addresses when targeting the RWPI
relocation model, we need to use base relative relocations. This patch
does the needed plumbing in MC to generate these for MOVW/MOVT.
Differential Revision: https://reviews.llvm.org/D29487
Change-Id: I446786e43a6f5aa9b6a5bb2cd216d60d41c7755d
llvm-svn: 294298
|
| |
|
|
| |
llvm-svn: 294297
|
| |
|
|
|
|
| |
Exposes some poor codegen with identity shuffle due to bad interaction with insert_subvector(extract_subvector) / concat_subvectors
llvm-svn: 294296
|
| |
|
|
|
| |
Review: https://reviews.llvm.org/D27749
llvm-svn: 294295
|
| |
|
|
|
|
| |
Also clean up logging and don't print \0.
llvm-svn: 294294
|
| |
|
|
|
|
|
| |
It looks like direct calls to mocked methods happen in the wild. This patch
add support for these as well.
llvm-svn: 294293
|
| |
|
|
| |
llvm-svn: 294292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clangd is a language server protocol implementation based on clang. It's
supposed to provide editor integration while not suffering from the
confined ABI of libclang.
This implementation is limited to the bare minimum functionality of
doing (whole-document) formatting and rangeFormatting. The JSON parsing
is based on LLVM's YAMLParser but yet most of the code of clangd is
currently dealing with JSON serialization and deserialization.
This was only tested with VS Code so far, mileage with other LSP clients
may vary.
Differential Revision: https://reviews.llvm.org/D29451
llvm-svn: 294291
|
| |
|
|
|
|
|
|
|
| |
We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.
Differential revision: https://reviews.llvm.org/D29582
llvm-svn: 294290
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we did not do that. For example, for R_386_PC8,
0xFF addend was not treated as 0xFFFFFFFF(-1),
but was 0x000000FF.
Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation
overflow as a result.
Differential revision: https://reviews.llvm.org/D29490
llvm-svn: 294289
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r294186.
On an internal test, this triggers an out-of-memory error on PPC,
presumably because there is another dagcombine that does the exact
opposite triggering and endless loop consuming more and more memory.
Chandler has started at creating a reduced test case and we'll attach it
as soon as possible.
llvm-svn: 294288
|
| |
|
|
|
|
| |
folding tables.
llvm-svn: 294287
|
| |
|
|
|
|
| |
This adds the masked versions of everything, but the shift by immediate instructions.
llvm-svn: 294286
|
| |
|
|
|
|
|
|
| |
This includes unmasked forms of variable shift and shifting by the lower element of a register.
Still need to do shift by immediate which was not foldable prior to avx512 and all the masked forms.
llvm-svn: 294285
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows setting LIBOMPTARGET_LLVM_LIT_EXECUTABLE and
LIBOMPTARGET_FILECHECK_EXECUTABLE as full path. It also honors
OPENMP_LLVM_TOOLS_DIR which is meant as a common configuration
for both libomp and libomptarget.
Maybe this should be done in a common CMake module, but I'm no expert here.
Differential Revision: https://reviews.llvm.org/D29172
llvm-svn: 294284
|
| |
|
|
|
|
| |
Address outstanding comments from https://reviews.llvm.org/D29267
llvm-svn: 294283
|
| |
|
|
|
|
| |
This reverts commit 7ac30e0f839fdab6d723ce2ef6a5b7a4cf03d150.
llvm-svn: 294282
|
| |
|
|
| |
llvm-svn: 294281
|
| |
|
|
|
|
|
| |
The parameter to /debugtype is user provided and may be invalid. Ensure
that we gracefully handle bad input.
llvm-svn: 294280
|
| |
|
|
|
|
|
|
| |
If `/debugtypes` is used to omit the codeview information, we would not
have constructed the debug info codeview record which is used to tie the
PDB to the binary. In such a case, rub out the GUID and Age fields.
llvm-svn: 294279
|
| |
|
|
|
|
|
| |
Make sure the spec required type alignments are used in preparation
for a possible change which may break this.
llvm-svn: 294278
|
| |
|
|
|
|
| |
YMM16-31.
llvm-svn: 294277
|
| |
|
|
| |
llvm-svn: 294276
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into CRTP base classes.
This can sometimes happen and not cause an immediate failure when the
derived class is, itself, a template. You can end up essentially calling
methods on the wrong derived type but a type where many things will
appear to "work".
To fail fast and with a clear error message we can use a static_assert,
but we have to stash that static_assert inside a method body or nested
type that won't need to be completed while building the base class. I've
tried to pick a reasonably small number of places that seemed like they
would definitely get triggered on use.
This is the last of the patch series defending against this that I have
planned, so far no bugs other than the original were found.
llvm-svn: 294275
|
| |
|
|
|
|
|
|
| |
This allows it to be used with the other sanitizers.
Differential Revision: https://reviews.llvm.org/D29545
llvm-svn: 294274
|
| |
|
|
| |
llvm-svn: 294273
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passed into CRTP base classes.
This can sometimes happen and not cause an immediate failure when the
derived class is, itself, a template. You can end up essentially calling
methods on the wrong derived type but a type where many things will
appear to "work".
To fail fast and with a clear error message we can use a static_assert,
but we have to stash that static_assert inside a method body or nested
type that won't need to be completed while building the base class. I've
tried to pick a reasonably small number of places that seemed like
reliably places for this to be instantiated.
llvm-svn: 294272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into CRTP base classes.
This can sometimes happen and not cause an immediate failure when the
derived class is, itself, a template. You can end up essentially calling
methods on the wrong derived type but a type where many things will
appear to "work".
To fail fast and with a clear error message we can use a static_assert,
but we have to stash that static_assert inside a method body or nested
type that won't need to be completed while building the base class. I've
tried to pick a reasonably small number of places that seemed like
reliably places for this to be instantiated.
llvm-svn: 294271
|
| |
|
|
|
|
|
|
| |
This really should get identified properly by the compiler to convert to
a NVRO, but compress the code anyways. This makes the implementation
identical to directory_iterator.cpp
llvm-svn: 294270
|
| |
|
|
|
|
| |
Reinstate r294256 with a fix.
llvm-svn: 294269
|
| |
|
|
|
|
|
|
|
|
|
| |
joinReservedPhysReg() can only deal with a liverange in a single basic
block when copying from a vreg into a physreg.
See also rdar://30306405
Differential Revision: https://reviews.llvm.org/D29436
llvm-svn: 294268
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch committed in r293017, as discussed on the list, doesn't really
make sense but was causing an actual issue to go away.
The issue turns out to be that in one place the extra template arguments
were dropped from the OuterAnalysisManagerProxy. This in turn caused the
types used in one set of places to access the key to be completely
different from the types used in another set of places for both Loop and
CGSCC cases where there are extra arguments.
I have literally no idea how anything seemed to work with this bug in
place. It blows my mind. But it did except for mingw64 in a DLL build.
I've added a really handy static assert that helps ensure we don't break
this in the future. It immediately diagnoses the issue with a compile
failure and a very clear error message. Much better that staring at
backtraces on a build bot. =]
llvm-svn: 294267
|
| |
|
|
|
|
|
|
|
|
|
| |
We model deduction-guides as functions with a new kind of name that identifies
the template whose deduction they guide; the bulk of this patch is adding the
new name kind. This gives us a clean way to attach an extensible list of guides
to a class template in a way that doesn't require any special handling in AST
files etc (and we're going to need these functions we come to performing
deduction).
llvm-svn: 294266
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For amdgcn target Clang generates addrspacecast to represent null pointers in private and local address spaces.
In LLVM codegen, the static variable initializer is lowered by virtual function AsmPrinter::lowerConstant which is target generic. Since addrspacecast is target specific, AsmPrinter::lowerConst
This patch overrides AsmPrinter::lowerConstant with AMDGPUAsmPrinter::lowerConstant, which is able to lower the target-specific addrspacecast in the null pointer representation so that -1 is co
Differential Revision: https://reviews.llvm.org/D29284
llvm-svn: 294265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the order in which LVI explores previously unexplored paths.
Previously, the code used an BFS strategy where each unexplored input was added to the search queue before any of them were explored. This has the effect of causing all inputs to be explored before returning to re-evaluate the merge point (non-local or phi node). This has the unfortunate property of doing redundant work if one of the inputs to the merge is found to be overdefined (i.e. unanalysable). If any input is overdefined, the result of the merge will be too; regardless of the values of other inputs.
The new code uses a DFS strategy where we re-evaluate the merge after evaluating each input. If we discover an overdefined input, we immediately return without exploring other inputs.
We have reports of large (4-10x) improvements of compile time with this patch and some reports of more precise analysis results as well. See the review discussion for details. The original motivating case was pr10584.
Differential Revision: https://reviews.llvm.org/D28190
llvm-svn: 294264
|
| |
|
|
|
|
|
| |
As noted in the comments, we should be able to eliminate cmp ops
in several cases.
llvm-svn: 294263
|
| |
|
|
|
|
| |
Otherwise there aren't any patterns to select them.
llvm-svn: 294261
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
direct call.
Summary: Checking CS.getCalledFunction() == nullptr does not necessary indicate indirect call. We also need to check if CS.getCalledValue() is not a constant.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29570
llvm-svn: 294260
|
| |
|
|
|
|
|
| |
This reverts commit r294256. It seems to be causing more problems instead
of solving them.
llvm-svn: 294259
|
| |
|
|
|
|
| |
Patch by Colin LeMahieu.
llvm-svn: 294258
|
| |
|
|
|
|
|
|
| |
There is typo in the debug output: top and bottom candidates are switched.
Differential Revision: https://reviews.llvm.org/D29608
llvm-svn: 294257
|
| |
|
|
| |
llvm-svn: 294256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a new clang-tidy module for safety-critical checks.
Include a check for inline assembler.
Reviewers: Prazek, dtarditi, malcolm.parsons, alexfh, aaron.ballman, idlecode
Reviewed By: idlecode
Subscribers: idlecode, JonasToth, Eugene.Zelenko, mgorny, JDevlieghere, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D29267
llvm-svn: 294255
|
| |
|
|
|
|
| |
multiplications with fastmath (PR31866)
llvm-svn: 294254
|
| |
|
|
|
|
|
|
|
| |
If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.
llvm-svn: 294253
|
| |
|
|
|
|
|
|
|
|
| |
We now create a dummy section with index 1 before processing the
linker script.
Thanks to George Rimar for finding the bug and providing the initial
testcase.
llvm-svn: 294252
|
| |
|
|
|
|
|
|
| |
from the end of two blocks, merge instead of arbitrarily picking one.
Differential Revision: http://reviews.llvm.org/D29504
llvm-svn: 294251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When instructions are hoisted, current implementation keeps DebugLoc metadata of the instruction that chosen as Repl (and its GEP operand if Repl is a load or a store). However, DebugLoc metadata should be updated to the 'merged' location across all hoisted instructions. See the following example code:
```
1: typedef struct {
2: int a[10];
3: } S1;
4:
5: extern S1 *s1[10];
6:
7: void foo(int x, int y, int i) {
8: if (y)
9: s1[i]->a[i] = x + y;
10: else
11: s1[i]->a[i] = x;
12: }
```
Below is LLVM IR representation of the program before gvn-hoist:
```
%struct.S1 = type { [10 x i32] }
@s1 = external local_unnamed_addr global [10 x %struct.S1*], align 16
define void @foo(i32 %x, i32 %y, i32 %i) !dbg !4 {
entry:
%tobool = icmp ne i32 %y, 0, !dbg !8
br i1 %tobool, label %if.then, label %if.else, !dbg !10
if.then: ; preds = %entry
%add = add nsw i32 %x, %y, !dbg !11
%idxprom = sext i32 %i to i64, !dbg !12
%arrayidx = getelementptr inbounds [10 x %struct.S1*], [10 x %struct.S1*]* @s1, i64 0, i64 %idxprom, !dbg !12
%0 = load %struct.S1*, %struct.S1** %arrayidx, align 8, !dbg !12, !tbaa !13
%a = getelementptr inbounds %struct.S1, %struct.S1* %0, i32 0, i32 0, !dbg !17
br label %if.end, !dbg !12
if.else: ; preds = %entry
%idxprom3 = sext i32 %i to i64, !dbg !18
%arrayidx4 = getelementptr inbounds [10 x %struct.S1*], [10 x %struct.S1*]* @s1, i64 0, i64 %idxprom3, !dbg !18
%1 = load %struct.S1*, %struct.S1** %arrayidx4, align 8, !dbg !18, !tbaa !13
%a5 = getelementptr inbounds %struct.S1, %struct.S1* %1, i32 0, i32 0, !dbg !19
br label %if.end
if.end: ; preds = %if.else, %if.then
%a5.sink = phi [10 x i32]* [ %a5, %if.else ], [ %a, %if.then ]
%.sink = phi i32 [ %x, %if.else ], [ %add, %if.then ]
%idxprom6 = sext i32 %i to i64
%arrayidx7 = getelementptr inbounds [10 x i32], [10 x i32]* %a5.sink, i64 0, i64 %idxprom6
store i32 %.sink, i32* %arrayidx7, align 4, !tbaa !20
ret void, !dbg !22
}
```
where
```
!11 = !DILocation(line: 9, column: 18, scope: !9)
!12 = !DILocation(line: 9, column: 5, scope: !9)
!18 = !DILocation(line: 11, column: 5, scope: !9)
!19 = !DILocation(line: 11, column: 9, scope: !9)
```
. And below is after gvn-hoist:
```
define void @foo(i32 %x, i32 %y, i32 %i) !dbg !4 {
entry:
%tobool = icmp ne i32 %y, 0, !dbg !8
%idxprom = sext i32 %i to i64, !dbg !10
%0 = getelementptr inbounds [10 x %struct.S1*], [10 x %struct.S1*]* @s1, i64 0, i64 %idxprom, !dbg !10
%1 = load %struct.S1*, %struct.S1** %0, align 8, !dbg !10, !tbaa !11
br i1 %tobool, label %if.then, label %if.else, !dbg !15
if.then: ; preds = %entry
%add = add nsw i32 %x, %y, !dbg !16
%arrayidx = getelementptr inbounds [10 x %struct.S1*], [10 x %struct.S1*]* @s1, i64 0, i64 %idxprom, !dbg !10
%a = getelementptr inbounds %struct.S1, %struct.S1* %1, i32 0, i32 0, !dbg !17
br label %if.end, !dbg !10
if.else: ; preds = %entry
%arrayidx4 = getelementptr inbounds [10 x %struct.S1*], [10 x %struct.S1*]* @s1, i64 0, i64 %idxprom, !dbg !18
%a5 = getelementptr inbounds %struct.S1, %struct.S1* %1, i32 0, i32 0, !dbg !19
br label %if.end
if.end: ; preds = %if.else, %if.then
%a5.sink = phi [10 x i32]* [ %a5, %if.else ], [ %a, %if.then ]
%.sink = phi i32 [ %x, %if.else ], [ %add, %if.then ]
%arrayidx7 = getelementptr inbounds [10 x i32], [10 x i32]* %a5.sink, i64 0, i64 %idxprom
store i32 %.sink, i32* %arrayidx7, align 4, !tbaa !20
ret void, !dbg !22
}
```
As you see, loads and their GEPs have been hosited from if.then/if.else block to entry block. However, DebugLoc metadata of these new instructions are still same as the instructions in if.then block, as they are moved/cloned from if.then block. This may result incorrect stepping and imprecise sample profile result.
Reviewers: majnemer, pcc, sebpop
Reviewed By: sebpop
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29377
llvm-svn: 294250
|
| |
|
|
|
|
|
|
| |
AArch64 was asserting when it was asked to provide a register-bank of a size it
couldn't deal with (in this case an s128 IMPLICIT_DEF). But we want a robust
fallback path so this isn't allowed.
llvm-svn: 294248
|
| |
|
|
|
|
|
| |
We don't handle all cases yet (see arm64-fallback.ll for an example), but this
is enough to cover most common C++ code so it's a good place to start.
llvm-svn: 294247
|