Follows the same lines as r186686, but much more limited, since we only
use ADD LOGICAL for multi-i64 additions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186689 91177308-0d34-0410-b5e6-96231b3b80d8
The atomic tests assume the two-operand forms, so I've restricted them to z10.
Running and-01.ll, or-01.ll and xor-01.ll for z196 as well as z10 shows why
using convertToThreeAddress() is better than exposing the three-operand forms
first and then converting back to two operands where possible (which is what
I'd originally tried). Using the three-operand form first stops us from
taking advantage of NG, OG and XG for spills.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186683 91177308-0d34-0410-b5e6-96231b3b80d8
This first step just adds definitions for SLLK, SRLK and SRAK.
The next patch will actually make use of them during codegen.
insn-bad.s tests that some form of error is reported when using these
instructions on z10. More work is needed to get the "instruction requires:
distinct-ops" that we'd ideally like, so I've stubbed that part out for now.
I'll come back and make it mandatory once the necessary changes are in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186680 91177308-0d34-0410-b5e6-96231b3b80d8
implementation of the SROA algorithm. We were using the term 'partition'
in many places that no longer ever represented an actual partition, but
rather just an arbitrary slice of an alloca.
No functionality change intended here. Mostly just renaming of types,
functions, variables, and rewording of comments. Several comments were
rewritten to make a lot more sense in the new structure of things.
The stats are still weird and not reflective of how this really works.
I'll fix those up in a separate patch as it is a touch more semantic of
a change...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186659 91177308-0d34-0410-b5e6-96231b3b80d8
SROA.
The crux of the issue is that now we track uses of a partition of the
alloca in two places: the iterators over the partitioning uses and the
previously collected split uses vector. We weren't accounting for the
fact that the split uses might invalidate integer widening in ways other
than due to their width (in this case due to being volatile).
Further reduced testcase added to the tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186655 91177308-0d34-0410-b5e6-96231b3b80d8
uses that wanted it. Also change the interface for createCompileUnit
to compensate. Fix comments that refer to TheCU as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186637 91177308-0d34-0410-b5e6-96231b3b80d8
1> Use DebugInfoFinder to find debug info MDNodes.
2> Add disable-debug-info-verifier to disable verifying debug info.
3> Disable verifying for testing cases that fail (will update the testing cases
later on).
4> MDNodes generated by clang can have empty filename for TAG_inheritance and
TAG_friend, so DIType::Verify is modified accordingly.
Note that DebugInfoFinder does not list all debug info MDNode.
For example, clang can generate:
metadata !{i32 786468}, which will fail to verify.
This MDNode is used by debug info but not included in DebugInfoFinder.
This MDNode is generated as a temporary node in DIBuilder::createFunction
Value *TElts[] = { GetTagConstant(VMContext, DW_TAG_base_type) };
MDNode::getTemporary(VMContext, TElts)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186634 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Dump optional data directory entries in the PE/COFF header, so that
we can test the output of LLD linker. This patch updates the test binary
file, but the source of the binary is the same. I just re-linked the file.
I don't know how the previous file was linked, but the previous file did
not have any data directory entries for some reason.
Reviewers: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1148
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186623 91177308-0d34-0410-b5e6-96231b3b80d8
uses that wanted it. Also change the interface for createCompileUnit
to compensate. Fix comments that refer to TheCU as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186599 91177308-0d34-0410-b5e6-96231b3b80d8
* assert that the return value is one of the documented values on msdn.
* on FILE_TYPE_UNKNOWN, check GetLastError.
Unfortunately I can't think of a way to get a FILE_TYPE_UNKNOWN on a test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186595 91177308-0d34-0410-b5e6-96231b3b80d8
The plan is to use it for clang and lld.
Major behavior changes:
- We can now parse UTF-16 files that have a byte order mark.
- PR16209: Don't drop backslashes on the floor if they don't escape
anything.
The actual parsing loop was based on code from Clang's driver.cpp,
although it's been rewritten to track its state with control flow rather
than state variables.
Reviewers: hans
Differential Revision: http://llvm-reviews.chandlerc.com/D1170
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186587 91177308-0d34-0410-b5e6-96231b3b80d8
The original code only folded SRA into ROTATE ... SELECTED BITS
if there was no outer shift. This patch splits out that check
and generalises it slightly. The extra cases aren't really that
interesting, but this is paving the way for RNSBG support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186571 91177308-0d34-0410-b5e6-96231b3b80d8
In hindsight, using "RISBG" for something that can be any type of
R.SBG instruction was a bit confusing, so this renames it to RxSBG.
That might not be the best choice either, since there is an instruction
called RXSBG, but hopefully the lower-case letter stands out enough.
While there I fixed a couple of GNUisms that had crept in --
sorry about that!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186569 91177308-0d34-0410-b5e6-96231b3b80d8
end of a vector. This was found with ASan. I've had one other report of
a crasher, but thus far been unable to reproduce the crash. It may well
be fixed with this version, and if not I'd like to get more information
from the build bots about what is happening.
See r186316 for the full commit log for the new implementation of the
SROA algorithm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186565 91177308-0d34-0410-b5e6-96231b3b80d8
Support for dynamic stack alignments in the PPC backend has been unfinished, in
part because it depends on dynamic stack realignment (which I only just
recently implemented fully). Now we can also support dynamic allocas with
higher than the default target stack alignment (16 bytes).
In order to round-up the requested size to the maximum requested alignment, we
need an additional register to hold the rounded-up size. We're already using one
scavenged register to hold the previous stack-pointer value (which needs to be
stored with the signal-safe stdux update), and so when we have dynamic allocas
and a large alignment, we allocate two emergency spill slots for the scavenger.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@186562 91177308-0d34-0410-b5e6-96231b3b80d8
