| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 209207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the results of a ComplexPattern check to be distributed to separate
named Operands, instead of the current system where all results must apply (and
match perfectly) with a single Operand.
For example, if "some_addrmode" is a ComplexPattern producing two results, you
can write:
def : Pat<(load (some_addrmode GPR64:$base, imm:$offset)),
(INST GPR64:$base, imm:$offset)>;
This should allow neater instruction definitions in TableGen that don't put all
possible aspects of addressing into a single operand, but are still usable with
relatively simple C++ CodeGen idioms.
llvm-svn: 209206
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 209203
|
| |
|
|
| |
llvm-svn: 209202
|
| |
|
|
| |
llvm-svn: 209201
|
| |
|
|
| |
llvm-svn: 209200
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple aliases overlap, the correct string to print can often be
determined purely by considering the InstAlias declarations in some particular
order. This allows the user to specify that order manually when desired,
without resorting to hacking around with the default lexicographical order on
Record instantiation, which is error-prone and ugly.
I was also mistaken about "add w2, w3, w4" being the same as "add w2, w3, w4,
uxtw". That's only true if Rn is the stack pointer.
llvm-svn: 209199
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
According to Intel Software Optimization Manual on Silvermont in some cases LEA
is better to be replaced with ADD instructions:
"The rule of thumb for ADDs and LEAs is that it is justified to use LEA
with a valid index and/or displacement for non-destructive destination purposes
(especially useful for stack offset cases), or to use a SCALE.
Otherwise, ADD(s) are preferable."
Differential Revision: http://reviews.llvm.org/D3826
llvm-svn: 209198
|
| |
|
|
|
|
|
|
| |
vectorizer. Now consistent with the remarks emitter.
Differential Revision: http://reviews.llvm.org/D3821
llvm-svn: 209197
|
| |
|
|
|
|
| |
Convert an additional site to a range based for loop. NFC.
llvm-svn: 209194
|
| |
|
|
|
|
| |
case as well as the case of a nonnull attribute (already handled but not tested).
llvm-svn: 209193
|
| |
|
|
|
|
|
|
| |
This workaround (presumably for ancient GDB) doesn't appear to be
required (GDB 7.5 seems to tolerate function definition DIEs in
namespace scope just fine).
llvm-svn: 209189
|
| |
|
|
|
|
| |
extra DW_TAG_class_type
llvm-svn: 209188
|
| |
|
|
| |
llvm-svn: 209187
|
| |
|
|
|
|
| |
pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden!
llvm-svn: 209185
|
| |
|
|
|
|
|
| |
Versions.
rdar://problem/16926122
llvm-svn: 209183
|
| |
|
|
|
|
| |
llvm-size to the list so it only has one. Sorry for the noise.
llvm-svn: 209181
|
| |
|
|
|
|
|
| |
check-llvm target under CMake. And the test/CMakeFiles.txt needs to
have llvm-size added to the list.
llvm-svn: 209179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
subprograms are constructed.
Since we visit the whole list of subprograms for each CU at module
start, this is clearly true - don't test for the case, just assert it.
A few old test cases seemed to have incomplete subprogram lists, but any
attempt to reproduce them shows full subprogram lists that even include
entities that have been completely inlined and the out of line
definition removed.
llvm-svn: 209178
|
| |
|
|
| |
llvm-svn: 209177
|
| |
|
|
|
|
|
| |
Patch by Dave Estes<cestes@codeaurora.org>!
PR19761 http://reviews.llvm.org/D3829
llvm-svn: 209176
|
| |
|
|
| |
llvm-svn: 209174
|
| |
|
|
| |
llvm-svn: 209173
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
times.
When I refactored this in r208636 I accidentally caused this to be added
multiple times to each abstract subprogram (not accounting for the
deduplicating effect of the InlinedSubprogramDIEs set).
This got better in r208798 when the abstract definitions got the
attribute added to them at construction time, but still had the
redundant copies introduced in r208636.
This commit removes those excess DW_AT_inlines and relies solely on the
insertion in r208798.
llvm-svn: 209166
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check in DwarfDebug::constructScopeDIE was meant to consider inlined
subroutines as any non-top-level scope that was a subprogram. Instead of
checking "not top level scope" it was checking if the /subprogram's/
scope was non-top-level.
Fix this and beef up a test case to demonstrate some of the missing
inlined_subroutines are no longer missing.
In the course of fixing this I also found that r208748 (with this fix)
found one /extra/ inlined_subroutine in concrete_out_of_line.ll due to
two inlined_subroutines having the same inlinedAt location. The previous
implementation was collapsing these into a single inlined subroutine.
I'm not sure what the original code was that created this .ll file so
I'm not sure if this actually happens in practice today. Since we
deliberately include column information to disambiguate two calls on the
same line, that may've addressed this bug in the frontend, but it's good
to know that workaround isn't necessary for this particular case
anymore.
llvm-svn: 209165
|
| |
|
|
| |
llvm-svn: 209164
|
| |
|
|
|
|
| |
This silences ~7 warnings on .c files in the LLVM build.
llvm-svn: 209163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types larger than i128.
Currently the X86 backend doesn't support types larger than i128 very well. For
example an i192 multiply will assert in codegen when the 2nd argument is a constant and the constant got hoisted.
This fix changes the cost model to never hoist constants for types larger than
i128. Once the codegen issues have been resolved, the cost model can be updated
to allow also larger types.
This is related to <rdar://problem/16954938>
llvm-svn: 209162
|
| |
|
|
|
|
|
|
|
|
| |
Instructions TZCNT (requires BMI1) and LZCNT (requires LZCNT), always
provide the operand size as output if the input operand is zero.
We can take advantage of this knowledge during instruction selection
stage in order to simplify a few corner case.
llvm-svn: 209159
|
| |
|
|
|
|
|
|
| |
so that llvm-size will total up all the sections in the Berkeley format. This
allows for rough categorizations for Mach-O sections. And allows the total of
llvm-size’s Berkeley and System V formats to be the same.
llvm-svn: 209158
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When inserting an element that's coming from a vector load or a broadcast
of a vector (or scalar) load, combine the load into the insertps
instruction.
Added PerformINSERTPSCombine for the case where we need to fix the load
(load of a vector + insertps with a non-zero CountS).
Added patterns for the broadcasts.
Also added tests for SSE4.1, AVX, and AVX2.
Reviewers: delena, nadav, craig.topper
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3581
llvm-svn: 209156
|
| |
|
|
|
|
|
|
| |
It turns out that not all the world is x86-64. Who knew?
I'll get to work on a more appropriate test case for this patch.
llvm-svn: 209155
|
| |
|
|
|
|
|
|
|
|
|
| |
For GOT relocations the addend should modify the offset to the
GOT entry, not the value of the entry itself. Teach RuntimeDyldMachO
to do The Right Thing here.
Fixes <rdar://problem/16961886>.
llvm-svn: 209154
|
| |
|
|
|
|
| |
for that.
llvm-svn: 209152
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3815
llvm-svn: 209150
|
| |
|
|
| |
llvm-svn: 209147
|
| |
|
|
| |
llvm-svn: 209139
|
| |
|
|
|
|
|
| |
Removes old 4096 byte workaround. This functionality has been available since
Windows XP.
llvm-svn: 209137
|
| |
|
|
|
|
|
|
| |
as it was causing build failures in ruby.
This reverts commit r207713.
llvm-svn: 209135
|
| |
|
|
| |
llvm-svn: 209134
|
| |
|
|
| |
llvm-svn: 209132
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3808
llvm-svn: 209129
|
| |
|
|
|
|
| |
case labels. No functional changes intended.
llvm-svn: 209126
|
| |
|
|
|
|
|
|
|
| |
The cost model conservatively assumes that it will always get scalarized and
that's about as good as we can get with the generic TTI; reasoning whether a
shuffle with an efficient lowering is available is hard. We can override that
conservative estimate for some targets in the future.
llvm-svn: 209125
|
| |
|
|
|
|
|
|
|
|
| |
bswap not.
- On ARM/ARM64 we get a vrev because the shuffle matching code is really smart. We still unroll anything that's not v4i32 though.
- On X86 we get a pshufb with SSSE3. Required more cleverness in isShuffleMaskLegal.
- On PPC we get a vperm for v8i16 and v4i32. v2i64 is unrolled.
llvm-svn: 209123
|
| |
|
|
|
|
|
|
|
|
|
| |
This removes TODO added in r208849 [http://reviews.llvm.org/D3629]
MIN(MIN(A, 97), 23) -> MIN(A, 23)
MAX(MAX(A, 23), 97) -> MAX(A, 97)
Differential Revision: http://reviews.llvm.org/D3785
llvm-svn: 209110
|
| |
|
|
| |
llvm-svn: 209107
|
| |
|
|
| |
llvm-svn: 209106
|
| |
|
|
| |
llvm-svn: 209105
|
| |
|
|
|
|
| |
versions are not used by lldb, lld, or clang.
llvm-svn: 209103
|