| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
[GlobalOpt] Remove unreachable blocks before optimizing a function.
While the change is presumably correct, it exposes a latent bug
in DI which breaks on of the CFI checks. I'll analyze it further
and try to understand what's going on.
llvm-svn: 307729
|
|
|
|
|
|
|
|
|
|
|
|
| |
I encountered these when linking LLD, which uses atls.lib. Those objects
appear to use these uncommon symbol records:
0x115E S_HEAPALLOCSITE
0x113D S_ENVBLOCK
0x1113 S_GTHREAD32
0x1153 S_FILESTATIC
llvm-svn: 307725
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenCL 2.0 introduces the notion of memory scopes in atomic operations to
global and local memory. These scopes restrict how synchronization is
achieved, which can result in improved performance.
This change extends existing notion of synchronization scopes in LLVM to
support arbitrary scopes expressed as target-specific strings, in addition to
the already defined scopes (single thread, system).
The LLVM IR and MIR syntax for expressing synchronization scopes has changed
to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this
replaces *singlethread* keyword), or a target-specific name. As before, if
the scope is not specified, it defaults to CrossThread/System scope.
Implementation details:
- Mapping from synchronization scope name/string to synchronization scope id
is stored in LLVM context;
- CrossThread/System and SingleThread scopes are pre-defined to efficiently
check for known scopes without comparing strings;
- Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in
the bitcode.
Differential Revision: https://reviews.llvm.org/D21723
llvm-svn: 307722
|
|
|
|
|
|
|
|
|
| |
Rename missing DEBUG_TYPE "machine-scheduler" from backend files, which were
absent from https://reviews.llvm.org/rL303921.
Differential revision: https://reviews.llvm.org/D35231
llvm-svn: 307719
|
|
|
|
| |
llvm-svn: 307717
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the .module and .set directives for the MT ASE,
notably that .module sets the relevant flags in .MIPS.abiflags and .set
doesn't.
Reviewers: slthakur, atanasyan
Differential Revision: https://reviews.llvm.org/D35249
llvm-svn: 307716
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For ELF, a movw+movt pair is handled as two separate relocations.
If an offset should be applied to the symbol address, this offset is
stored as an immediate in the instruction (as opposed to stored as an
offset in the relocation itself).
Even though the actual value stored in the movt immediate after linking
is the top half of the value, we need to store the unshifted offset
prior to linking. When the relocation is made during linking, the offset
gets added to the target symbol value, and the upper half of the value
is stored in the instruction.
This makes sure that movw+movt with offset symbols get properly
handled, in case the offset addition in the lower half should be
carried over to the upper half.
This makes the output from the additions to the test case match
the output from GNU binutils.
For COFF and MachO, the movw/movt relocations are handled as a pair,
and the overflow from the lower half gets carried over to the movt,
so they should keep the shifted offset just as before.
Differential Revision: https://reviews.llvm.org/D35242
llvm-svn: 307713
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, rengolin
Reviewed By: t.p.northover
Subscribers: aemerson, javed.absar, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D35266
llvm-svn: 307706
|
|
|
|
|
|
| |
wasn't unrolled.
llvm-svn: 307705
|
|
|
|
|
|
|
|
|
|
| |
This is fine as nothing in the code relies on leader and memory
leader being the same for a given congruency class. Ack'ed by
Dan.
Fixes PR33720.
llvm-svn: 307699
|
|
|
|
| |
llvm-svn: 307694
|
|
|
|
| |
llvm-svn: 307692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
./FuzzerIOWindows.cpp:185:1: warning: multi-line comment [-Wcomment]
// Parse a directory ending in separator, like: SomeDir\
^
./FuzzerIOWindows.cpp:200:1: warning: multi-line comment [-Wcomment]
// Parse a servername and share, like: SomeServer\SomeShare\
^
```
Differential Revision: https://reviews.llvm.org/D35244
llvm-svn: 307687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The warning is reproducible with GCC 4.8. Thanks to David Blaikie for
the suggested fix.
The reported warning was
```
/usr/local/google/home/echristo/sources/llvm/lib/Fuzzer/FuzzerExtFunctions.def:29:10: warning: ISO C++ forbids casting between pointer-to-function and pointer-to-object [-Wpedantic]
EXT_FUNC(__lsan_enable, void, (), false);
^
/usr/local/google/home/echristo/sources/llvm/lib/Fuzzer/FuzzerExtFunctionsWeak.cpp:44:24: note: in definition of macro ‘EXT_FUNC’
CheckFnPtr((void *)::NAME, #NAME, WARN);
^
```
Differential Revision: https://reviews.llvm.org/D35243
llvm-svn: 307686
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR33347: https://bugs.llvm.org/show_bug.cgi?id=33347.
Differential Revision: https://reviews.llvm.org/D35160
Patch by Matt Morehouse.
llvm-svn: 307684
|
|
|
|
|
|
|
|
|
|
| |
Preparatory work for adding the MIPS MT (multi-threading) ASE instructions.
Reviewers: slthakur, atanasyan
Differential Revision: https://reviews.llvm.org/D35247
llvm-svn: 307679
|
|
|
|
|
|
|
|
| |
This reverts commit r307573.
This breaks downstream test.
llvm-svn: 307678
|
|
|
|
|
|
|
|
|
|
| |
The loop structure for the outer loop does not contain the epilog
preheader when we try to unroll inner loop with multiple exits and
epilog code is generated. For now, we just bail out in such cases.
Added a test case that shows the problem. Without this bailout, we would
trip on assert saying LCSSA form is incorrect for outer loop.
llvm-svn: 307676
|
|
|
|
| |
llvm-svn: 307675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Patch by Klaus Kretzschmar
We would like to introduce a new type of llvm error handler for handling
bad alloc fault situations. LLVM already provides a fatal error handler
for serious non-recoverable error situations which by default writes
some error information to stderr and calls exit(1) at the end (functions
are marked as 'noreturn').
For long running processes (e.g. a server application), exiting the
process is not an acceptable option, especially not when the system is
in a temporary resource bottleneck with a good chance to recover from
this fault situation. In such a situation you would rather throw an
exception to stop the current compilation and try to overcome the
resource bottleneck. The user should be aware of the problem of throwing
an exception in bad alloc situations, e.g. you must not do any
allocations in the unwind chain. This is especially true when adding
exceptions in existing unfamiliar code (as already stated in the comment
of the current fatal error handler)
So the new handler can also be used to distinguish from general fatal
error situations where recovering is no option. It should be used in
cases where a clean unwind after the allocation is guaranteed.
This patch contains:
- A report_bad_alloc function which calls a user defined bad alloc
error handler. If no user handler is registered the
report_fatal_error function is called. This function is not marked as
'noreturn'.
- A install/restore_bad_alloc_error_handler to install/restore the bad
alloc handler.
- An example (in Mutex.cpp) where the report_bad_alloc function is
called in case of a malloc returns a nullptr.
If this patch gets accepted we would create similar patches to fix
corresponding malloc/calloc usages in the llvm code.
Reviewers: chandlerc, greened, baldrick, rnk
Reviewed By: rnk
Subscribers: llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D34753
llvm-svn: 307673
|
|
|
|
|
|
|
|
|
|
|
| |
1. The available program storage region of the red zone to compilers is 288
bytes rather than 244 bytes.
2. The formula for negative number alignment calculation should be
y = x & ~(n-1) rather than y = (x + (n-1)) & ~(n-1).
Differential Revision: https://reviews.llvm.org/D34337
llvm-svn: 307672
|
|
|
|
|
|
|
|
| |
Patch by Michael Wu.
Differential Revision: https://reviews.llvm.org/D35104
llvm-svn: 307671
|
|
|
|
|
|
| |
FirstInBundle, NFCI.
llvm-svn: 307667
|
|
|
|
|
|
| |
subclasses.
llvm-svn: 307666
|
|
|
|
| |
llvm-svn: 307662
|
|
|
|
|
|
|
| |
Some minor corrections for the recently added instructions.
Review: Ulrich Weigand
llvm-svn: 307658
|
|
|
|
|
|
| |
Map the result into GPR and the operands into FPR.
llvm-svn: 307653
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows the pc to be used as a destination register for the
pseudo instruction LDR pc,=expression . The pseudo instruction must not be
transformed into a MOV, but it can use the Thumb2 LDR (literal) instruction
to a constant pool entry. See (A7.7.43 from ARMv7M ARM ARM).
Differential Revision: https://reviews.llvm.org/D34751
llvm-svn: 307640
|
|
|
|
|
|
|
| |
We used to forget to erase the original instruction when replacing a
G_FCMP true/false. Fix this bug and make sure the tests check for it.
llvm-svn: 307639
|
|
|
|
|
|
|
|
|
|
|
|
| |
TreePatternNode considers them to be plain integers but MachineInstr considers
them to be a distinct kind of operand.
The tweak to AArch64InstrInfo.td to produce a simple test case is a NFC for
everything except GlobalISelEmitter (confirmed by diffing the tablegenerated
files). GlobalISelEmitter is currently unable to infer the type of operands in
the Dst pattern from the operands in the Src pattern.
llvm-svn: 307634
|
|
|
|
|
|
| |
Same as the s32 version, for both hard and soft float.
llvm-svn: 307633
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a second attempt to land this patch.
The first one resulted in a crash of clang sanitizer buildbot.
The fix is here and regression test is added.
This is a last fix for the corner case of PR32214. Actually this is not really corner case in general.
We should not do a loop rotation if we create an additional branch due to it.
Consider the case where we have a loop chain H, M, B, C , where
H is header with viable fallthrough from pre-header and exit from the loop
M - some middle block
B - backedge to Header but with exit from the loop also.
C - some cold block of the loop.
Let's H is determined as a best exit. If we do a loop rotation M, B, C, H we can introduce the extra branch.
Let's compute the change in number of branches:
+1 branch from pre-header to header
-1 branch from header to exit
+1 branch from header to middle block if there is such
-1 branch from cold bock to header if there is one
So if C is not a predecessor of H then we introduce extra branch.
This change actually prohibits rotation of the loop if both true
Best Exit has next element in chain as successor.
Last element in chain is not a predecessor of first element of chain.
Reviewers: iteratee, xur, sammccall, chandlerc
Reviewed By: iteratee
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34745
llvm-svn: 307631
|
|
|
|
|
|
| |
AND8ri8 not supported in 64bit.
llvm-svn: 307630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenPrepare::optimizeMemoryInst contains a check that we do nothing
if all instructions combining the address for memory instruction is in the same
block as memory instruction itself.
However if any of these instruction are placed after memory instruction then
address calculation will not be folded to memory instruction.
The added test case shows an example.
Reviewers: loladiro, spatel, efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34862
llvm-svn: 307628
|
|
|
|
| |
llvm-svn: 307626
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
querying for analysis results on a function declaration rather than
a definition.
The only reason this worked previously is by chance -- because the way
we got alias analysis results with the legacy PM, we happened to not
compute a dominator tree and so we happened to not hit an assert even
though it didn't make any real sense. Now we bail out before trying to
compute alias analysis so that we don't hit these asserts.
llvm-svn: 307625
|
|
|
|
|
|
|
|
|
| |
In the POWER9 instruction scheduler, SchedWriteRes for the simple integer instructions are misconfigured to use that of (costly) DFU instructions.
This results in surprisingly long instruction latency estimation and causes misbehavior in some optimizers such as if-conversion.
Differential Revision: https://reviews.llvm.org/D34869
llvm-svn: 307624
|
|
|
|
|
|
|
|
|
|
| |
This patch reduces compilation time by avoiding redundant analysis while selecting instructions to create an immediate.
If the instruction count required to create the input number without rotate is 2, we do not need further analysis to find a shorter instruction sequence with rotate; rotate + load constant cannot be done by 1 instruction (i.e. getInt64CountDirectnever return 0).
This patch should not change functionality.
Differential Revision: https://reviews.llvm.org/D34986
llvm-svn: 307623
|
|
|
|
| |
llvm-svn: 307622
|
|
|
|
|
|
| |
It will only ever contain one register.
llvm-svn: 307620
|
|
|
|
| |
llvm-svn: 307619
|
|
|
|
| |
llvm-svn: 307617
|
|
|
|
| |
llvm-svn: 307614
|
|
|
|
|
|
|
|
| |
aliasSameBasePointerGEPs() if no phis have been visited yet."
It broke stage2 tests in selfhosting.
llvm-svn: 307613
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D35233
llvm-svn: 307612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is part of the continuing effort to increase parity between
LLD and MSVC PDBs. link still doesn't like our PDBs, so the most
obvious thing to check was whether adding an empty publics stream
would get it to do something else. It still fails in the same way
but at least this removes one more variable from the equation.
The next logical step would be to try creating an empty globals
stream.
Differential Revision: https://reviews.llvm.org/D35224
llvm-svn: 307598
|
|
|
|
| |
llvm-svn: 307597
|
|
|
|
|
|
|
|
|
| |
Reverting as it breaks tramp3d-v4 in the llvm test-suite. I added some
comments to https://reviews.llvm.org/D33345 about it.
This reverts commit r307546.
llvm-svn: 307589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As metioned in https://reviews.llvm.org/D34576, checkings in
`collectConstantCandidates` can be replaced by using
`llvm::canReplaceOperandWithVariable`.
The only special case is that `collectConstantCandidates` return false for
all `IntrinsicInst` but it is safe for us to collect constant candidates from
`IntrinsicInst`.
Reviewers: pirama, efriedma, srhines
Reviewed By: efriedma
Subscribers: llvm-commits, javed.absar
Differential Revision: https://reviews.llvm.org/D34921
llvm-svn: 307587
|
|
|
|
| |
llvm-svn: 307586
|