This commit fixes the code which adds lifetime markers in InlineFunction to skip
zero-sized allocas instead of asserting on them.
rdar://problem/20531155
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235312 91177308-0d34-0410-b5e6-96231b3b80d8
n/1 generates a quotient equal to n and a remainder of 0.
If this case is not recognized, then the SCEV divide() function
can return a remainder that is greater than or equal to the
denominator, which means the delinearized subscripts for the
test case will be incorrect.
Differential Revision: http://reviews.llvm.org/D9003
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235311 91177308-0d34-0410-b5e6-96231b3b80d8
The current implementations could exhibit some behavior differences:
raw_fd_ostream: Whatever the underlying fd does with seek+write. In a normal
file, the write position would be back to the old offset.
raw_svector_ostream: The write position is always the end of the stream, so
after pwrite the write position would be the new end. This matches what OS_X
(all BSD?) do with a pwrite in a O_APPEND fd.
Given that we don't need that feature and don't use O_APPEND a lot in LLVM,
just disallow it.
I am open to suggestions on renaming pwrite to something else, but this fixes
the issue for now.
Thanks to Yaron Keren for reporting it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235303 91177308-0d34-0410-b5e6-96231b3b80d8
We have to avoid converting a reference to a global into a reference to a local,
but it is fine to look past a local.
Patch by Vasileios Kalintiris.
I just moved the comment and added thet test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235300 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression introduced at revision 231243.
The target-independent selection algorithm in FastISel knows how to select
a SINT_TO_FP if the target is SSE but not AVX. That is because on X86, the
tablegen'd 'fastEmit' functions know how to select CVTSI2SSrr and CVTSI2SDrr.
Method X86FastISel::X86SelectSIToFP was therefore working under the
wrong assumption that the target was AVX. That assumption was incorrect since
we can have a target that is neither AVX nor SSE.
So, rather than asserting for the presence of AVX, we should have had an
early exit from 'X86SelectSIToFP' if the target was not AVX.
This patch fixes the issue replacing the invalid assertion with an early exit.
Thanks to Dimitry Andric for reporting this problem and for providing a small
reproducible testcase. Added test pr23273.ll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235295 91177308-0d34-0410-b5e6-96231b3b80d8
When an inline asm call has an output register marked as early-clobber, but
that same register is also an input operand, what should we do? GCC accepts
this, and is documented to accept this for read/write operands saying,
"Furthermore, if the earlyclobber operand is also a read/write operand, then
that operand is written only after it's used." For write-only operands, the
situation seems less clear, but I have at least one existing codebase that
assumes this will work, in part because it has syscall macros like this:
({ \
register uint64_t r0 __asm__ ("r0") = (__NR_ ## name); \
register uint64_t r3 __asm__ ("r3") = ((uint64_t) (arg0)); \
register uint64_t r4 __asm__ ("r4") = ((uint64_t) (arg1)); \
register uint64_t r5 __asm__ ("r5") = ((uint64_t) (arg2)); \
__asm__ __volatile__ \
("sc" \
: "=&r"(r0),"=&r"(r3),"=&r"(r4),"=&r"(r5) \
: "0"(r0), "1"(r3), "2"(r4), "3"(r5) \
: "r6","r7","r8","r9","r10","r11","r12","cr0","memory"); \
r3; \
})
Furthermore, with register aliases and subregister relationships that only the
backend knows about, rejecting this in the frontend seems like a difficult
proposition (if we wanted to do so). However, keeping the early-clobber flag on
the INLINEASM MI does not work for us, because it will cause the register's
live interval to end to soon (so it will not appear defined to be used as an
input).
Fortunately, fixing this does not seem hard: When forming the INLINEASM MI,
check to see if any of the early-clobber outputs are also inputs, and if so,
remove the early-clobber flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235283 91177308-0d34-0410-b5e6-96231b3b80d8
The fix ensures that scalar sources inserted into a vector are the correct bit size.
Integer scalar sources from BUILD_VECTOR and SCALAR_TO_VECTOR nodes may require truncation that this function doesn't currently support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235281 91177308-0d34-0410-b5e6-96231b3b80d8
Harden r235258 to support any integer bitwidth. The quick glance at
the reference made me think only i32 and i64 were valid types, but
they're not special, so any overload is legal.
Thanks to David Majnemer for noticing!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235261 91177308-0d34-0410-b5e6-96231b3b80d8
Followup to r235232, which caused PR23278.
We can't assume the memset and memcpy sizes have the same type, as
nothing in the language reference prevents that.
Instead, zext both to i64 if they disagree.
While there, robustify tests by using i8 %c rather than i8 0 for the
memset character.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235258 91177308-0d34-0410-b5e6-96231b3b80d8
Multiplying INT_MIN by 1 doesn't trigger nsw. However, shifting 1 into
the sign bit *does* trigger nsw.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235250 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235249 91177308-0d34-0410-b5e6-96231b3b80d8
Delete `DIDescriptor` and update the remaining users. I'll follow-up by
deleting subclasses in manageable groups (top-down).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235248 91177308-0d34-0410-b5e6-96231b3b80d8
The result is either an Untyped reg sequence, on ldN with N > 1, or
just the type of the input vector, on ld1. Don't force Untyped.
Instead, just use the type of the reg sequence.
This mirrors the behavior of createTuple, which feeds the LD1*_POST.
The narrow code path wasn't actually covered by tests, because V64
insert_vector_elt are widened to V128 before the LD1LANEpost combine
has the chance to run, usually.
The only case where it does run on V64 vectors is if the vector ops
legalizer ran. So, tickle the code with a ctpop.
Fixes PR23265.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235243 91177308-0d34-0410-b5e6-96231b3b80d8
Stop using `DIDescriptor` and its subclasses in the `DebugInfoFinder`
API, as well as the rest of the API hanging around in `DebugInfo.h`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235240 91177308-0d34-0410-b5e6-96231b3b80d8
Previously DebugInfoPDB could only load data for a PDB given a
path to the PDB. It could not open an EXE and find the matching
PDB and verify it matched, etc. This patch adds support for that
so that we can simply load debug information for a PDB directly.
Additionally, this patch extends DebugInfoPDB to support getting
source and line information for symbols.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235237 91177308-0d34-0410-b5e6-96231b3b80d8
The implementation of this GEP::getResultElementType will be refactored
to either rely on a member variable, or recompute the value from the
indicies (any preferences?).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235236 91177308-0d34-0410-b5e6-96231b3b80d8
A common idiom in some code is to do the following:
memset(dst, 0, dst_size);
memcpy(dst, src, src_size);
Some of the memset is redundant; instead, we can do:
memcpy(dst, src, src_size);
memset(dst + src_size, 0,
dst_size <= src_size ? 0 : dst_size - src_size);
Original patch by: Joel Jones
Differential Revision: http://reviews.llvm.org/D498
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235232 91177308-0d34-0410-b5e6-96231b3b80d8
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235229 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to r235222, but for the weak symbol case.
In an "ideal" assembler/object format an expression would always refer to the
final value and A-B would only be computed from a section in the same
comdat as A and B with A and B strong.
Unfortunately that is not the case with debug info on ELF, so we need an
heuristic. Since we need an heuristic, we may as well use the same one as
gas:
* call weak_sym : produces a relocation, even if in the same section.
* A - weak_sym and weak_sym -A: don't produce a relocation if we can
compute it.
This fixes pr23272 and changes the fix of pr22815 to match what gas does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235227 91177308-0d34-0410-b5e6-96231b3b80d8
They would break the SelectionDAG.
Note that the opposite load->vector dependency is already obvious in:
(LD1*post vec, ..)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235224 91177308-0d34-0410-b5e6-96231b3b80d8
CatchHigh may be smaller than TryHigh if we reuse an outlined catch
handler for two different invokes with different EH states. We have no
evidence which shows that CatchHigh must be greater than TryHigh or
TryLow. We can revisit this if we turn out to be wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235223 91177308-0d34-0410-b5e6-96231b3b80d8
Part of pr23272.
A small annoyance with the assembly syntax we implement is that given an
expression there is no way to know if what is desired is the value of that
expression for the symbols in this file or for the final values of those
symbols in a link.
The first case is useful for use in sections that get discarded or ignored
if the section they are describing is discarded.
For axample, consider A-B where A and B are in the same comdat section.
We can compute the value of the difference in the section that is present in
the current .o and if that section survives to the final DSO the value will
still will be correct.
But the section is in a comdat. Another section from another object file
might be used istead. We know that that section will define A and B, but
we have no idea what the value of A-B might be.
In practice we have to assume that the intention is to compute the value
in the current section since otherwise the is no way to create something like
the debug aranges section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235222 91177308-0d34-0410-b5e6-96231b3b80d8
Now (with a few carefully placed suppressions relating to general type
serialization, etc) we can round trip a simple load through bitcode and
textual IR without calling getElementType on a PointerType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235221 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
- Handle TypePromoteFloat in switch statements
- Move an expression into an assert to avoid unused variable in
non-assert builds.
Reviewers: srhines, ab
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9086
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235220 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds legalization support to operate on FP16 as a load/store type
and do operations on it as floats.
Tests for ARM are added to test/CodeGen/ARM/fp16-promote.ll
Reviewers: srhines, t.p.northover
Differential Revision: http://reviews.llvm.org/D8755
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235215 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Implement the method FastMaterializeAlloca in Mips fast-isel
Based on a patch by Reed Kotler.
Test Plan:
Passes test-suite at O0/O2 for mips32 r1/r2
fastalloca.ll
Reviewers: dsanders, rkotler
Subscribers: rfuhler, llvm-commits
Differential Revision: http://reviews.llvm.org/D6742
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235213 91177308-0d34-0410-b5e6-96231b3b80d8
Catch blocks which are empty may be in the same state as their try
blocks. It is not meaningful to give the catch block its own state
number in this case because it can't do anything exceptional.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235212 91177308-0d34-0410-b5e6-96231b3b80d8
When debugging LTO issues with ld64, we use -save-temps to save the merged
optimized bitcode file, then invoke ld64 again on the single bitcode file.
The saved bitcode file is already internalized, so we can call
lto_codegen_set_should_internalize and skip running internalization again.
rdar://20227235
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235211 91177308-0d34-0410-b5e6-96231b3b80d8
