This re-applies r262886 with a fix for 32 bit platforms that have 8 byte
pointer alignment, effectively reverting r262892.
Original Message:
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262902 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like the largest SDNode is different between 32 and 64 bit now,
so this is breaking 32 bit bots. Reverting while I figure out a fix.
This reverts r262886.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262892 91177308-0d34-0410-b5e6-96231b3b80d8
Currently some SDNode operands are malloc'd, some are stored inline in
subclasses of SDNode, and some are thrown into a BumpPtrAllocator.
This scheme is complex, inconsistent, and makes refactoring SDNodes
fairly difficult.
Instead, we can allocate all of the operands using an ArrayRecycler
that wraps a BumpPtrAllocator. This keeps the cache locality when
iterating operands, improves locality when iterating SDNodes without
looking at operands, and vastly simplifies the ownership semantics.
It also means we stop overallocating SDNodes by 2-3x and will make it
simpler to fix the rampant undefined behaviour we have in how we
mutate SDNodes from one kind to another (See llvm.org/pr26808).
This is NFC other than the changes in memory behaviour, and I ran some
LNT tests to make sure this didn't hurt compile time. Not many tests
changed: there were a couple of 1-2% regressions reported, but there
were more improvements (of up to 4%) than regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262886 91177308-0d34-0410-b5e6-96231b3b80d8
Before this change, we would get the type definition in the middle
of the instruction.
E.g., %0(48) = G_ADD %struct_alias = type { i32, i16 } %edi, %edi
Now, we have just the expected type name:
%0(48) = G_ADD %struct_alias %edi, %edi
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262885 91177308-0d34-0410-b5e6-96231b3b80d8
Without actually parsing a type it is difficult to perdict where
the type definition ends. In other words, instead of expecting
the user of the parser API to hand over only the relevant bits
of the string being parsed, take the whole string, parse the type,
and get back the number of characters that have been read.
This will be used by the MIR testing infrastructure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262884 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-config can know tell whether or not a build has been configured to support
global-isel.
Use '--has-global-isel' for that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262877 91177308-0d34-0410-b5e6-96231b3b80d8
TSan instrumentation functions for atomic stores, loads, and cmpxchg work on
integer value types. This patch adds casts before calling TSan instrumentation
functions in cases where the value is a pointer.
Differential Revision: http://reviews.llvm.org/D17833
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262876 91177308-0d34-0410-b5e6-96231b3b80d8
Now the type API is always available, but when global-isel is not
built the implementation does nothing.
Note: The implementation free of ifdefs is WIP and tracked here in PR26576.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262873 91177308-0d34-0410-b5e6-96231b3b80d8
The mir infrastructure will need this for generic instructions and currently
this feature was only available through the anonymous TypePrinter class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262869 91177308-0d34-0410-b5e6-96231b3b80d8
This is useful for MIR serialization. Indeed generic machine instructions
must have a type and we don't want to duplicate the logic in the MIParser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262868 91177308-0d34-0410-b5e6-96231b3b80d8
This lets select sub-targets enable this pass. The patch implements the
idea from the recent llvm-dev thread:
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/94925
The goal is to enable the LoopDataPrefetch pass for the Cyclone
sub-target only within Aarch64.
Positive and negative tests will be included in an upcoming patch that
enables selective prefetching of large-strided accesses on Cyclone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262844 91177308-0d34-0410-b5e6-96231b3b80d8
Until now curly braces could only be used in MS inline assembly to mark block start/end.
All curly braces were removed completely at a very early stage.
This approach caused bugs like:
"m{o}v eax, ebx" turned into "mov eax, ebx" without any error.
In addition, AVX-512 added special operands (e.g., k registers), which are also surrounded by curly braces that mark them as such.
Now, we need to keep the curly braces and identify at a later stage if they are marking block start/end (if so, ignore them), or surrounding special AVX-512 operands (if so, parse them as such).
This patch fixes the bug described above and enables the use of AVX-512 special operands.
This commit is the the llvm part of the patch.
The clang part of the review is: http://reviews.llvm.org/D17766
The llvm part of the review is: http://reviews.llvm.org/D17767
Differential Revision: http://reviews.llvm.org/D17767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262843 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This testcase had me confused. It made me believe that you can use
alias scopes and alias scopes list interchangeably with alias.scope and
noalias. Both langref and the other testcase use scope lists so I went
looking.
Turns out using scope directly only happens to work by chance. When
ScopedNoAliasAAResult::mayAliasInScopes traverses this as a scope list:
!1 = !{!1, !0, !"some scope"}
, the first entry is in fact a scope but only because the scope is
happened to be defined self-referentially to make it unique globally.
The remaining elements in the tuple (!0, !"some scope") are considered
as scopes but AliasScopeNode::getDomain will just bail on those without
any error.
This change avoids this ambiguity in the test but I've also been
wondering if we should issue some sort of a diagnostics.
Reviewers: dexonsmith, hfinkel
Subscribers: mssimpso, llvm-commits
Differential Revision: http://reviews.llvm.org/D16670
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262841 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r262250.
It causes SPEC2006/gcc to generate wrong result (166.s) in AArch64 when
running with *ref* data set. The error happens with
"-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262839 91177308-0d34-0410-b5e6-96231b3b80d8
This code has been successfully used to bootstrap libc++ in a no-asserts
mode for a very long time, so the code that follows cannot be completely
incorrect. I've added a test that shows the current behavior for this
kind of code with DFSan. If it is desirable for DFSan to do something
special when processing an invoke of a variadic function, it can be
added, but we shouldn't keep an assert that we've been ignoring due to
release builds anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262829 91177308-0d34-0410-b5e6-96231b3b80d8
This is much more clear and less surprising IMO. It also makes things
more consistent with the increasingly large chunk of LLVM code that
assumes true-on-success.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262826 91177308-0d34-0410-b5e6-96231b3b80d8
duplicated comments.
In several cases these had diverged making them especially nice to
canonicalize. I checked to make sure we weren't losing important
information of course.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262825 91177308-0d34-0410-b5e6-96231b3b80d8
