| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes in X86.td:
I set features of Intel processors in incremental form: IVB = SNB + X HSW = IVB + X ..
I added Skylake client processor and defined it's features
FeatureADX was missing on KNL
Added some new features to appropriate processors SMAP, IFMA, PREFETCHWT1, VMFUNC and others
Differential Revision: http://reviews.llvm.org/D16357
llvm-svn: 258659
|
|
|
|
| |
llvm-svn: 258658
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16137
llvm-svn: 258657
|
|
|
|
| |
llvm-svn: 258655
|
|
|
|
|
|
|
|
|
| |
SCCP has code identical to changeToUnreachable's behavior, switch it
over to just call changeToUnreachable.
No functionality change intended.
llvm-svn: 258654
|
|
|
|
|
|
|
|
|
| |
InstCombine and SCCP both want to remove dead code in a very particular
way but using identical means to do so. Share the code between the two.
No functionality change is intended.
llvm-svn: 258653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A cleanup can have paths which unwind or end up in unreachable.
If there is an unreachable path *and* a path which unwinds to caller,
we would mistakenly inject an unwind path to a catchswitch on the
unreachable path. This results in a verifier assertion firing because
the cleanup unwinds to two different places: to the caller and to the
catchswitch.
This occured because we used getCleanupRetUnwindDest to determine if the
cleanuppad had no cleanuprets.
This is incorrect, getCleanupRetUnwindDest returns null for cleanuprets
which unwind to caller.
llvm-svn: 258651
|
|
|
|
|
|
| |
The documentation for these functions is already present in the header file.
llvm-svn: 258649
|
|
|
|
|
|
| |
The documentation for these methods is already present in the header.
llvm-svn: 258648
|
|
|
|
|
|
| |
BUILD_VECTOR and UNDEF folding.
llvm-svn: 258646
|
|
|
|
|
|
| |
Generalised mask generation / subvector extraction to use the input/output types directly instead of an if/else through all the currently accepted types.
llvm-svn: 258645
|
|
|
|
|
|
| |
Make use of DAG.getBitcast and use clang-format to reduce number of lines (and make it more readable).
llvm-svn: 258644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, we would just output "foo = bar" in the assembly, and then
ptxas would choke. Now we die before emitting any invalid code.
Reviewers: echristo
Subscribers: jholewinski, llvm-commits, jhen, tra
Differential Revision: http://reviews.llvm.org/D16490
llvm-svn: 258638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before:
.func (.param .b32 func_retval0) _ZL21__nvvm_reflect_anchorv(
)
{
After:
.func (.param .b32 func_retval0) _ZL21__nvvm_reflect_anchorv()
{
Reviewers: bkramer
Subscribers: llvm-commits, tra, jhen, echristo, jholewinski
Differential Revision: http://reviews.llvm.org/D16512
llvm-svn: 258637
|
|
|
|
|
|
| |
ilist::size() is O(n) while ilist::empty() is O(1)
llvm-svn: 258636
|
|
|
|
| |
llvm-svn: 258631
|
|
|
|
|
|
|
|
|
|
|
| |
target is macho.
It looks like the check for macho was accidentally dropped in r132959.
I don't have a test case, but I'll add one if anyone knows how this can
be tested.
llvm-svn: 258627
|
|
|
|
| |
llvm-svn: 258626
|
|
|
|
| |
llvm-svn: 258624
|
|
|
|
|
|
| |
If the INSERTPS zeroes out all the referenced elements from either of the 2 input vectors (and the input is not already UNDEF), then set that input to UNDEF to reduce dependencies.
llvm-svn: 258622
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now LIR can turn following codes into memset:
typedef struct foo {
int a;
int b;
} foo_t;
void bar(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; ++i) {
f[i].a = 0;
f[i].b = 0;
}
}
void test(foo_t *f, unsigned n) {
for (unsigned i = 0; i < n; i += 2) {
f[i] = 0;
f[i+1] = 0;
}
}
llvm-svn: 258620
|
|
|
|
|
|
|
|
|
| |
Seems like some compilers still give unused variable warnings for
bool var = ...;
(void)var;
so I have to inline the variable.
llvm-svn: 258619
|
|
|
|
| |
llvm-svn: 258618
|
|
|
|
| |
llvm-svn: 258617
|
|
|
|
|
|
| |
LLVM's BasicBlock has a single terminator, it is not valid to have two.
llvm-svn: 258616
|
|
|
|
| |
llvm-svn: 258615
|
|
|
|
|
|
| |
Replace tests with lrp with basic IR expansion
llvm-svn: 258612
|
|
|
|
|
|
|
|
|
| |
Instead of RAUW with undef, replace the first non-token instruction with
unreachable.
This fixes PR26263.
llvm-svn: 258611
|
|
|
|
|
|
| |
No functionality change is intended.
llvm-svn: 258610
|
|
|
|
|
|
|
|
| |
PruneEH had functionality idential to removeUnwindEdge.
Consolidate around removeUnwindEdge.
No functionality change is intended.
llvm-svn: 258609
|
|
|
|
| |
llvm-svn: 258608
|
|
|
|
|
|
| |
This has side effects.
llvm-svn: 258607
|
|
|
|
|
|
|
| |
This is a leftover from AMDIL that doesn't do anything
and doesn't belong here.
llvm-svn: 258606
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the conditions necessary to produce ccmp sequences were only
checked in recursive calls to emitConjunctionDisjunctionTree() after
some of the earlier expressions were already built. Move all checks over
to isConjunctionDisjunctionTree() so they are all checked before we
start emitting instructions.
Also rename some variable to better reflect their usage.
llvm-svn: 258605
|
|
|
|
|
|
|
|
|
| |
isConjunctionDisjunctionTree()
This function will exhibit exponential runtime (2**n) so we should
rather use a lower limit.
llvm-svn: 258604
|
|
|
|
| |
llvm-svn: 258603
|
|
|
|
|
|
|
|
|
| |
Previously it failed to add NumArgRegs to the offset and so clobbered an
already-used register. Now just start the numbering after the arg regs
and don't duplicate the add. Test coverage for this coming shortly with
the implementation of byval.
llvm-svn: 258597
|
|
|
|
|
|
| |
and successes
llvm-svn: 258589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanups in C++ are a little weird. They are only guaranteed to be
reliably executed if, and only if, there is a viable catch handler which
can handle the exception.
This means that reachability of a cleanup is lexically determined by it
being nested with a try-block which unwinds to a catch. It is *cannot*
be reasoned about by examining the control flow edges leaving a cleanup.
Usually this is not a problem. It becomes a problem when there are *no*
edges out of a cleanup because we believed that code post-dominated by
the cleanup is dead. In LLVM's case, this code is what informs the
personality routine about the presence of a suitable catch handler.
However, the lack of edges to that catch handler makes the handler
become unreachable which causes us to remove it. By removing the
handler, the cleanup becomes unreachable.
Instead, inject a catch-all handler with every cleanup that has no
unwind edges. This will allow us to properly unwind the stack.
This fixes PR25997.
llvm-svn: 258580
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in MachOObjectFile::getSymbolByIndex() when a Mach-O file has
a symbol table load command but the number of symbols are zero.
The code in MachOObjectFile::symbol_begin_impl() should not be
assuming there is a symbol at index 0, in cases there is no symbol
table load command or the count of symbol is zero. So I also fixed
that. And needed to fix MachOObjectFile::symbol_end_impl() to
also do the same thing for no symbol table or one with zero entries.
The code in MachOObjectFile::getSymbolByIndex() should trigger
the report_fatal_error() for programmatic errors for any index when
there is no symbol table load command and not return the end iterator.
So also fixed that. Note there is no test case as this is a programmatic
error.
The test case using the file macho-invalid-bad-symbol-index has
a symbol table load command with its number of symbols (nsyms)
is zero. Which was incorrectly testing the bad triggering of the
report_fatal_error() in in MachOObjectFile::getSymbolByIndex().
This test case is an invalid Mach-O file but not for that reason.
It appears this Mach-O file use to have an nsyms value of 11,
and what makes this Mach-O file invalid is the counts and
indexes into the symbol table of the dynamic load command
are now invalid because the number of symbol table entries
(nsyms) is now zero. Which can be seen with the existing
llvm-obdump:
% llvm-objdump -private-headers macho-invalid-bad-symbol-index
…
Load command 4
cmd LC_SYMTAB
cmdsize 24
symoff 4216
nsyms 0
stroff 4392
strsize 144
Load command 5
cmd LC_DYSYMTAB
cmdsize 80
ilocalsym 0
nlocalsym 8 (past the end of the symbol table)
iextdefsym 8 (greater than the number of symbols)
nextdefsym 2 (past the end of the symbol table)
iundefsym 10 (greater than the number of symbols)
nundefsym 1 (past the end of the symbol table)
...
And the native darwin tools generates an error for this file:
% nm macho-invalid-bad-symbol-index
nm: object: macho-invalid-bad-symbol-index truncated or malformed object (ilocalsym plus nlocalsym in LC_DYSYMTAB load command extends past the end of the symbol table)
I added new checks for the indexes and sizes for these in the
constructor of MachOObjectFile. And added comments for what
would be a proper diagnostic messages.
And changed the test case using macho-invalid-bad-symbol-index
to test for the new error now produced.
Also added a test with a valid Mach-O file with a symbol table
load command where the number of symbols is zero that shows
the report_fatal_error() is not called.
llvm-svn: 258576
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix the issue with the most recently discovered unit receiving much less attention.
Note: this is the second attempt (prev: r258473). Now, libc++ build is fixed.
Reviewers: aizatsky, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16487
llvm-svn: 258571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The testing for returnBB was flipped which may cause ARM ld/st opt pass uses callee saved regs in returnBB when shrink-wrap is used.
Reviewers: t.p.northover, apazos, MatzeB
Subscribers: mcrosier, zzheng, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D16434
llvm-svn: 258569
|
|
|
|
| |
llvm-svn: 258567
|
|
|
|
| |
llvm-svn: 258558
|
|
|
|
|
|
|
|
|
|
|
| |
The intrinsic target prefix should match the target name
as it appears in the triple.
This is not yet complete, but gets most of the important ones.
llvm.AMDGPU.* intrinsics used by mesa and libclc are still handled
for compatability for now.
llvm-svn: 258557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all the attributes from the base object.
Summary:
Make sure that any new and optimized objects created during GlobalOPT copy all the attributes from the base object.
A good example of improper behavior in the current implementation is section information associated with the GlobalObject. If a section was set for it, and GlobalOpt is creating/modifying a new object based on this one (often copying the original name), without this change new object will be placed in a default section, resulting in inappropriate properties of the new variable.
The argument here is that if customer specified a section for a variable, any changes to it that compiler does should not cause it to change that section allocation.
Moreover, any other properties worth representation in copyAttributesFrom() should also be propagated.
Reviewers: jmolloy, joker-eph, joker.eph
Subscribers: slarin, joker.eph, rafael, tobiasvk, llvm-commits
Differential Revision: http://reviews.llvm.org/D16074
llvm-svn: 258556
|
|
|
|
| |
llvm-svn: 258552
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds a `-spp-no-statepoints` flag to PlaceSafepoints that
bypasses the code that wraps newly introduced polls and existing calls
in gc.statepoint. With `-spp-no-statepoints` enabled, PlaceSafepoints
effectively becomes a safpeoint **poll** insertion pass.
The eventual goal is to "constant fold" this option, along with
`-rs4gc-use-deopt-bundles` to `true`, once clients using gc.statepoint
are okay doing so.
Reviewers: pgavlin, reames, JosephTremoulet
Subscribers: sanjoy, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D16439
llvm-svn: 258551
|
|
|
|
|
|
|
|
| |
Make the variable a member of the writer trait object owned
now by the writer. Also use a different generator interface
to pass the infoObject from the writer.
llvm-svn: 258544
|
|
|
|
| |
llvm-svn: 258538
|