| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation of SCEVExpander demonstrates a very naive behavior when
it deals with power calculation. For example, a SCEV for x^8 looks like
(x * x * x * x * x * x * x * x)
If we try to expand it, it generates a very straightforward sequence of muls, like:
x2 = mul x, x
x3 = mul x2, x
x4 = mul x3, x
...
x8 = mul x7, x
This is a non-efficient way of doing that. A better way is to generate a sequence of
binary power calculation. In this case the expanded calculation will look like:
x2 = mul x, x
x4 = mul x2, x2
x8 = mul x4, x4
In some cases the code size reduction for such SCEVs is dramatic. If we had a loop:
x = a;
for (int i = 0; i < 3; i++)
x = x * x;
And this loop have been fully unrolled, we have something like:
x = a;
x2 = x * x;
x4 = x2 * x2;
x8 = x4 * x4;
The SCEV for x8 is the same as in example above, and if we for some reason
want to expand it, we will generate naively 7 multiplications instead of 3.
The BinPow expansion algorithm here allows to keep code size reasonable.
This patch teaches SCEV Expander to generate a sequence of BinPow multiplications
if we have repeating arguments in SCEVMulExpressions.
Differential Revision: https://reviews.llvm.org/D34025
llvm-svn: 305663
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section "Arguments" of `getelementptr` [1] says the first argument is a
type, the second argument is a pointer or a vector of pointers, and is
the base address to start from. Update `getelementptr` FAQ [2]
accordingly, based on discussion with David on the mailing list [3].
[1] http://llvm.org/docs/LangRef.html#getelementptr-instruction
[2] http://llvm.org/docs/GetElementPtr.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2017-June/114294.html
Patch by Wei-Ren Chen!
Differential Revision: https://reviews.llvm.org/D34325
llvm-svn: 305662
|
| |
|
|
| |
llvm-svn: 305657
|
| |
|
|
| |
llvm-svn: 305656
|
| |
|
|
| |
llvm-svn: 305655
|
| |
|
|
| |
llvm-svn: 305654
|
| |
|
|
|
|
|
|
| |
Merge the functionality into the random access type collection.
This class was only being used in 2 places, so getting rid of it
simplifies the code.
llvm-svn: 305653
|
| |
|
|
|
|
| |
integerPart typedef at file scope and just use the one in APFloatBase everywhere. NFC
llvm-svn: 305652
|
| |
|
|
|
|
| |
This should compile to slightly better code.
llvm-svn: 305651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
NetBSD ships with PaX MPROTECT disallowing RWX mappings.
There is a solution to bypass this restriction with double mapping
RX (code) and RW (data) using mremap(2) MAP_REMAPDUP.
The initial mapping must be mmap(2)ed with protection:
PROT_MPROTECT(PROT_EXEC).
This functionality to bypass PaX MPROTECT appeared in NetBSD-7.99.72.
This patch fixes 20 failing tests:
- LLVM :: DebugInfo/debuglineinfo-macho.test
- LLVM :: DebugInfo/debuglineinfo.test
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_Mips64r2N64_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N32_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_N64R6_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32R6_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/Mips/ELF_O32_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_i386.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/COFF_x86_64.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF-relaxed.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_STT_FILE.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PC8_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x64-64_PIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_PIC-small-relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86-64_debug_frame.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/ELF_x86_64_StubBuf.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_empty_ehframe.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_DynNoPIC_relocations.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_i386_eh_frame.s
- LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, lhames
Reviewed By: joerg
Subscribers: sdardis, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D33874
llvm-svn: 305650
|
| |
|
|
|
|
| |
Increment (add 1) could be transformed to sub -1, and we'd lose coverage for these patterns.
llvm-svn: 305646
|
| |
|
|
|
|
| |
Increment (add 1) could be transformed to sub -1, and we'd lose coverage for these patterns.
llvm-svn: 305645
|
| |
|
|
|
|
| |
Increment (add 1) could be transformed to sub -1, and we'd lose coverage for these patterns.
llvm-svn: 305644
|
| |
|
|
| |
llvm-svn: 305643
|
| |
|
|
| |
llvm-svn: 305642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(string) passed to them.
Summary:
This allows strlen to be moved out of the loop in case its argument is
not modified in the loop in LICM.
Reviewers: hfinkel, davide, sanjoy, dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34323
llvm-svn: 305641
|
| |
|
|
| |
llvm-svn: 305640
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: C.f. http://llvm.org/docs/LangRef.html#non-integral-pointer-type
Reviewers: chandlerc, loladiro
Reviewed By: loladiro
Subscribers: reames, loladiro, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D32203
llvm-svn: 305639
|
| |
|
|
| |
llvm-svn: 305637
|
| |
|
|
| |
llvm-svn: 305636
|
| |
|
|
|
|
| |
CMake-3.9 doesn't let compilation units depend on their dependent libraries.
llvm-svn: 305635
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM_DEFAULT_TARGET_TRIPLE at runtime.
No behavior is changed if LLVM_TARGET_TRIPLE_ENV is blank or undefined.
If LLVM_TARGET_TRIPLE_ENV is "TEST_TARGET_TRIPLE" and $TEST_TARGET_TRIPLE is not blank,
llvm::sys::getDefaultTargetTriple() returns $TEST_TARGET_TRIPLE.
Lit resets config.target_triple and config.environment[LLVM_TARGET_TRIPLE_ENV] to change the default target.
Without changing LLVM_DEFAULT_TARGET_TRIPLE nor rebuilding, lit can be run;
TEST_TARGET_TRIPLE=i686-pc-win32 bin/llvm-lit -sv path/to/test/
TEST_TARGET_TRIPLE=i686-pc-win32 ninja check-clang-tools
Differential Revision: https://reviews.llvm.org/D33662
llvm-svn: 305632
|
| |
|
|
| |
llvm-svn: 305630
|
| |
|
|
| |
llvm-svn: 305629
|
| |
|
|
| |
llvm-svn: 305628
|
| |
|
|
| |
llvm-svn: 305627
|
| |
|
|
| |
llvm-svn: 305626
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-apply r276044/r279124/r305516. Fixed a problem where we would refuse
to place spills as the very first instruciton of a basic block and thus
artifically increase pressure (test in
test/CodeGen/PowerPC/scavenging.mir:spill_at_begin)
This is a variant of scavengeRegister() that works for
enterBasicBlockEnd()/backward(). The benefit of the backward mode is
that it is not affected by incomplete kill flags.
This patch also changes
PrologEpilogInserter::doScavengeFrameVirtualRegs() to use the register
scavenger in backwards mode.
Differential Revision: http://reviews.llvm.org/D21885
llvm-svn: 305625
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is my misunderstanding on isBarrier. It's not for memory barriers,
but for other control flow purposes. lwsync doesn't have it either.
This fixes a simple crash with -verify-machineinstrs like below:
define void @Foo() {
entry:
%tmp = load atomic i64, i64* undef acquire, align 8
unreachable
}
I deliberately don't want to check in the test, since there is little
chance to regress on such a mistake. Such a test adds noise to the code
base.
I plan to check in first, since it fixes a crash, and the fix is obvious.
Reviewers: kbarton, echristo
Subscribers: sanjoy, nemanjai, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D34314
llvm-svn: 305624
|
| |
|
|
|
|
| |
The analysis is expected to be preserved by SelectionDAG.
llvm-svn: 305621
|
| |
|
|
|
|
|
|
| |
Fixes PR33453.
Differential Revision: https://reviews.llvm.org/D34303
llvm-svn: 305618
|
| |
|
|
|
|
|
| |
This was a regression introduced in a previous patch. Adding
back the code that handles this case.
llvm-svn: 305617
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that symbolic relocations are generated for stack
pointer manipulations.
These relocations are of type R_WEBASSEMBLY_GLOBAL_INDEX_LEB.
This change also adds support for reading relocations of this
type in WasmObjectFile.cpp.
Since its a globally imported symbol this does mean that
the get_global/set_global instruction won't be valid until
the objects are linked that global used in no longer an
imported global.
Differential Revision: https://reviews.llvm.org/D34172
llvm-svn: 305616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppose we had a type index offsets array with a boundary at type index
N. Then you request the name of the type with index N+1, and that name
requires the name of index N-1 (think a parameter list, for example). We
didn't handle this, and we would print something like (<unknown UDT>,
<unknown UDT>).
The fix for this is not entirely trivial, and speaks to a larger
problem. I think we need to kill TypeDatabase, or at the very least kill
TypeDatabaseVisitor. We need a thing that doesn't do any caching
whatsoever, just given a type index it can compute the type name "the
slow way". The reason for the bug is that we don't have anything like
that. Everything goes through the type database, and if we've visited a
record, then we're "done". It doesn't know how to do the expensive thing
of re-visiting dependent records if they've not yet been visited.
What I've done here is more or less copied the code (albeit greatly
simplified) from TypeDatabaseVisitor, but wrapped it in an interface
that just returns a std::string. The logic of caching the name is now in
LazyRandomTypeCollection. Eventually I'd like to move the record
database here as well and the visited record bitfield here as well, at
which point we can actually just delete TypeDatabase. I don't see any
reason for it if a "sequential" collection is just a special case of a
random access collection with an empty partial offsets array.
Differential Revision: https://reviews.llvm.org/D34297
llvm-svn: 305612
|
| |
|
|
|
|
|
| |
I'm trying to get rid of the TypeDatabase class, so the first
step is to minimize its footprint.
llvm-svn: 305611
|
| |
|
|
|
|
|
|
|
|
| |
Previously only the error codes were reported which
meant that useful information about malformed inputs
was not shown.
Differential Revision: https://reviews.llvm.org/D34008
llvm-svn: 305609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Davide Italiano reported the following issue if llvm
is compiled with gcc -Wstrict-aliasing -Werror:
.....
lib/Target/BPF/CMakeFiles/LLVMBPFCodeGen.dir/BPFISelDAGToDAG.cpp.o
../lib/Target/BPF/BPFISelDAGToDAG.cpp: In member function ‘virtual
void {anonymous}::BPFDAGToDAGISel::PreprocessISelDAG()’:
../lib/Target/BPF/BPFISelDAGToDAG.cpp:264:26: warning: dereferencing
type-punned pointer will break strict-aliasing rules
[-Wstrict-aliasing]
val = *(uint16_t *)new_val;
.....
The error is caused by my previous commit (revision 305560).
This patch fixed the issue by introducing an union to avoid
type casting.
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 305608
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As far as I can tell we should be able to implement these almost the same way we do unsigned, but using signed comparisons and checks for min signed value instead of min unsigned value.
Reviewers: pete, davide, sanjoy
Reviewed By: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33815
llvm-svn: 305607
|
| |
|
|
| |
llvm-svn: 305606
|
| |
|
|
| |
llvm-svn: 305605
|
| |
|
|
|
|
| |
getting the underlying APInt first. NFC
llvm-svn: 305604
|
| |
|
|
| |
llvm-svn: 305603
|
| |
|
|
| |
llvm-svn: 305602
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the following motivating example
bool c();
void f();
bool start() {
bool result = c();
if (!c()) {
result = false;
goto exit;
}
f();
result = true;
exit:
return result;
}
we would previously generate a single DW_AT_const_value(1) because
only the DBG_VALUE in the second-to-last basic block survived
codegen. This patch improves the heuristic used to determine when a
DBG_VALUE is available at the beginning of its variable's enclosing
lexical scope:
- Stop giving singular constants blanket permission to take over the
entire scope. There is still a special case for constants in the
function prologue that we also miight want to retire later.
- Use the lexical scope information to determine available-at-entry
instead of proximity to the function prologue.
After this patch we generate a location list with a more accurate
narrower availability for the constant true value. As a pleasant side
effect, we also generate inline locations instead of location lists
where a loacation covers the entire range of the enclosing lexical
scope.
Measured on compiling llc with four targets this doesn't have an
effect on compile time and reduces the size of the debug info for llc
by ~600K.
rdar://problem/30286912
llvm-svn: 305599
|
| |
|
|
|
|
| |
monorepo.
llvm-svn: 305598
|
| |
|
|
|
|
|
|
|
|
| |
the object.
The verifier should not output any message in such a case.
Added test case with no .apple_name section in the file to verify new functionality.
Made existing test case more specific.
llvm-svn: 305597
|
| |
|
|
| |
llvm-svn: 305596
|
| |
|
|
|
|
| |
Found by -Wpessimizing-move.
llvm-svn: 305595
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this patch, I flip the switch in DriverUtils from using the external
cvtres.exe tool to using the Windows Resource library in llvm.
I also fixed a bug where .rsrc sections were marked as discardable
memory and therefore were placed in the wrong order in the final PE.
Furthermore, I modified WindowsResource to write the coff directly to a
memory buffer instead of to file, also had it use the machine types
already declared in COFF.h instead creating my own enum.
Finally, I flipped the switch to allow all unit tests that had
previously run only on windows due to a winres dependency to run
cross-platform.
Reviewers: zturner, ruiu
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D34265
llvm-svn: 305592
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
folding phis
Summary:
When we fold vector constants that are operands of phi's that feed into select,
we need to set the correct insertion point for the *new* selects that get generated.
The correct insertion point is the incoming block for the phi.
Such cases can occur with patch r298845, which fixed folding of
vector constants, but the new selects could be inserted incorrectly (as the added
test case shows).
Reviewers: majnemer, spatel, sanjoy
Reviewed by: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34162
llvm-svn: 305591
|