| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Also, replace win and linux runs with a generic run because that
makes no difference in what this test is checking.
llvm-svn: 235361
|
| |
|
|
| |
llvm-svn: 235360
|
| |
|
|
|
|
| |
outlining.
llvm-svn: 235358
|
| |
|
|
|
|
|
| |
Delete subclasses of (the already defunct) `DIScope`, updating users to
use the raw pointers from the `Metadata` hierarchy directly.
llvm-svn: 235356
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9125
llvm-svn: 235354
|
| |
|
|
|
|
|
| |
Pretty sure the build was broken by r235327 (I updated it there, but
apparently didn't check if it compiled).
llvm-svn: 235353
|
| |
|
|
|
|
|
|
|
|
|
| |
Delete subclasses of (the already deleted) `DIType` in favour of
directly using pointers from the `Metadata` hierarchy.
While `DICompositeType` wraps `MDCompositeTypeBase` and `DIDerivedType`
wraps `MDDerivedTypeBase`, most uses of each really meant the more
specific `MDCompositeType` and `MDDerivedType`.
llvm-svn: 235351
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The version of `constructTypeDIE()` for `MDSubroutineType` is unrelated
to (and has different callers than) the `MDCompositeType`. Split the
two in half.
This simplifies an upcoming patch to delete `DICompositeType`. There
shouldn't be any real functionality change here. `createTypeDIE()` is
`cast<>`'ing where it didn't need to before, but that function in turn
is only called for true `MDCompositeType`s.
llvm-svn: 235349
|
| |
|
|
|
|
|
|
|
|
|
| |
the function body.
This is necessary for correctness when lazily compiling.
Also, flesh out the Orc unit test infrastructure slightly, and add a unit test
for this.
llvm-svn: 235347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update comment style in `DwarfUnit`.
- Drop duplicated comments at definition, and update the comments at
the declaration where the definition comments looked newer or more
complete.
- Drop the `functionName -` prefix.
- Add `\brief` in a few places.
- Remove a few comments entirely that weren't adding value (just
turned the function name and arguments into a sentence).
llvm-svn: 235345
|
| |
|
|
| |
llvm-svn: 235344
|
| |
|
|
| |
llvm-svn: 235342
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Set operation action for FP16 conversion opcodes, so the Op legalizer
can choose the gnu_* libcalls for Mips.
Set LoadExtAction and TruncStoreAction for f16 scalars and vectors to
prevent (fpext (load )) and (store (fptrunc)) from getting combined into
unsupported operations.
Added test cases to test that these operations are handled correctly
for f16 scalars and vectors. This patch depends on
http://reviews.llvm.org/D8755.
Reviewers: srhines
Subscribers: llvm-commits, ab
Differential Revision: http://reviews.llvm.org/D8804
llvm-svn: 235341
|
| |
|
|
|
|
|
|
| |
This folds:
(select (setcc x, -0.0, *lt), NaN, (fsqrt x)) -> ( fsqrt x)
llvm-svn: 235333
|
| |
|
|
|
|
| |
This is a wrapper around APFloat::getNaN().
llvm-svn: 235332
|
| |
|
|
|
|
|
|
| |
This is the last major parent class, so I'll probably start deleting
classes in batches now. Looks like many of the references to the DI*
hierarchy were updated organically along the way.
llvm-svn: 235331
|
| |
|
|
| |
llvm-svn: 235328
|
| |
|
|
|
|
|
|
|
| |
Replace uses of `DIScope` with `MDScope*`. There was one spot where
I've left an `MDScope*` uninitialized (where `DIScope` would have been
default-initialized to `nullptr`) -- this is intentional, since the
if/else that follows should unconditional assign it to a value.
llvm-svn: 235327
|
| |
|
|
| |
llvm-svn: 235325
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds the following targets to cmake. These can be used to build and link only specific parts of a backend, instead of having to link the whole backend.
- AllTargetsAsmPrinters, AllTargetsAsmParsers, AllTargetsDescs, AllTargetsDisassemblers, AllTargetsInfos
A typical use for these is instead of linking ${LLVM_TARGETS_TO_BUILD}. This commit changes llvm-mc to show how to use the new targets.
Reviewed by Chris Bieneman.
llvm-svn: 235324
|
| |
|
|
|
|
|
|
|
|
| |
Remove typedefs for type refs:
- DITypeRef => MDTypeRef
- DIScopeRef => MDScopeRef
- DIDescriptorRef => DebugNodeRef
llvm-svn: 235323
|
| |
|
|
|
|
|
|
| |
Implement BITSWAP instruction using mapping.
Differential Revision: http://reviews.llvm.org/D8857
llvm-svn: 235321
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Patch by: John Brawn
Reviewers: jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9105
llvm-svn: 235314
|
| |
|
|
|
|
|
|
|
| |
This commit fixes the code which adds lifetime markers in InlineFunction to skip
zero-sized allocas instead of asserting on them.
rdar://problem/20531155
llvm-svn: 235312
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 235311
|
| |
|
|
| |
llvm-svn: 235310
|
| |
|
|
| |
llvm-svn: 235309
|
| |
|
|
|
|
|
|
| |
Implement disassembler support for microMIPS32r6.
Differential Revision: http://reviews.llvm.org/D8490
llvm-svn: 235307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 235303
|
| |
|
|
|
|
|
|
| |
This patch implements BALC and BC instructions using mapping.
Differential Revision: http://reviews.llvm.org/D8388
llvm-svn: 235302
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 235300
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8387
llvm-svn: 235298
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D8386
llvm-svn: 235296
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion (PR23273).
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.
llvm-svn: 235295
|
| |
|
|
| |
llvm-svn: 235287
|
| |
|
|
| |
llvm-svn: 235285
|
| |
|
|
|
|
|
|
|
| |
This patch refactors reduction identification code out of LoopVectorizer and
exposes them as common utilities.
No functional change.
Review: http://reviews.llvm.org/D9046
llvm-svn: 235284
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 235283
|
| |
|
|
|
|
|
|
|
|
| |
requiring truncation.
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.
llvm-svn: 235281
|
| |
|
|
|
|
| |
and constant folding.
llvm-svn: 235279
|
| |
|
|
|
|
| |
No functional changes.
llvm-svn: 235278
|
| |
|
|
| |
llvm-svn: 235269
|
| |
|
|
| |
llvm-svn: 235268
|
| |
|
|
| |
llvm-svn: 235267
|
| |
|
|
| |
llvm-svn: 235266
|
| |
|
|
|
|
| |
not used anywhere in llvm.
llvm-svn: 235265
|
| |
|
|
| |
llvm-svn: 235262
|
| |
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 235261
|
| |
|
|
| |
llvm-svn: 235260
|
| |
|
|
| |
llvm-svn: 235259
|