Summary:
These operands had the same purpose, however the MipsMemSimm9GPRAsmOperand
operand was only for micromips32r6 and the MipsMemSimm9AsmOperand did not
have a ParserMatchClass.
Patch by Scott Egerton
Reviewers: vkalintiris, dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12730
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247573 91177308-0d34-0410-b5e6-96231b3b80d8
GetElementPointers must have the first argument's type compared
for structural equivalence. Previously the code erroneously compared the
pointer's type, but this code was dead because all pointer types (of the
same address space) are the same. The pointee must be compared instead
(using the type stored in the GEP, not from the pointer type which will
be erased anyway).
Author: jrkoenig
Reviewers: dschuff, nlewycky, jfb
Subscribers: nlewycky, llvm-commits
Differential revision: http://reviews.llvm.org/D12820
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247570 91177308-0d34-0410-b5e6-96231b3b80d8
Turning (op x (mul y k)) into (op x (lsl (mul y k>>n) n)) is beneficial when
we can do the lsl as a shifted operand and the resulting multiply constant is
simpler to generate.
Do this by doing the transformation when trying to select a shifted operand,
as that ensures that it actually turns out better (the alternative would be to
do it in PreprocessISelDAG, but we don't know for sure there if extracting the
shift would allow a shifted operand to be used).
Differential Revision: http://reviews.llvm.org/D12196
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247569 91177308-0d34-0410-b5e6-96231b3b80d8
The MipsTargetELFStreamer can receive ABI info from many sources. For example,
from the MipsAsmParser instance. Lifetime of the MipsAsmParser can be shorter
than MipsTargetELFStreamer's lifetime. In that case we get a dangling pointer
to MipsABIInfo.
Differential Revision: http://reviews.llvm.org/D12805
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247546 91177308-0d34-0410-b5e6-96231b3b80d8
DeletionCallbackHandle holds GAR in its creation. It assumes;
- It is registered as CallbackVH. It should not be moved in its life.
- Its parent, GAR, may be moved.
To move list<DeletionCallbackHandle> GlobalsAAResult::Handles,
GAR must be updated with the destination in GlobalsAAResult(&&).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247534 91177308-0d34-0410-b5e6-96231b3b80d8
that could be used from a new pass manager. This one makes particular
sense as a static helper as it doesn't even need TLI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247525 91177308-0d34-0410-b5e6-96231b3b80d8
of a method and into a re-usable static helper. We can potentially use
this function from the implementation of a new pass manager oriented
version of the pass. Also add some better documentation of exactly what
the semantic model of this routine is (it isn't trivial) and use a more
modern naming convention for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247524 91177308-0d34-0410-b5e6-96231b3b80d8
static function rather than a method. It just needed access to
TargetLibraryInfo, and this way it can be easily reused between the
current FunctionAttrs implementation and any port for the new pass
manager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247522 91177308-0d34-0410-b5e6-96231b3b80d8
methods. They don't need anything from the class anyways.
Also, collect the declarations into the private section of the pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247521 91177308-0d34-0410-b5e6-96231b3b80d8
comments, deleting duplicate comments, moving comments to consistently
live on the definition since these are all really internal routines,
etc. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247520 91177308-0d34-0410-b5e6-96231b3b80d8
Before we just printed on stderr the program name. Now at least we
print the name of the file that doesn't exist. There's probably room
for improvement of error handling in llvm-mc (and the tools in general),
but still this is a step forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247518 91177308-0d34-0410-b5e6-96231b3b80d8
The changes in:
test/CodeGen/X86/machine-cp.ll
are just due to scheduling differences after some logic instructions were reassociated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247516 91177308-0d34-0410-b5e6-96231b3b80d8
Renamed to lowerVectorShuffleAsPermuteAndUnpack to make it clear that it lowers to more than just a UNPCK instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247513 91177308-0d34-0410-b5e6-96231b3b80d8
Improved InstCombine support for CVTPH2PS (F16C half 2 float conversion):
<4 x float> @llvm.x86.vcvtph2ps.128(<8 x i16>) - only uses the bottom 4 i16 elements for the conversion.
Added constant folding support.
Differential Revision: http://reviews.llvm.org/D12731
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247504 91177308-0d34-0410-b5e6-96231b3b80d8
In some ways this is a very boring port to the new pass manager as there
are no interesting analyses or dependencies or other oddities.
However, this does introduce the first good example of a transformation
pass with non-trivial state porting to the new pass manager. I've tried
to carve out patterns here to replicate elsewhere, and would appreciate
comments on whether folks like these patterns:
- A common need in the new pass manager is to effectively lift the pass
class and some of its state into a public header file. Prior to this,
LLVM used anonymous namespaces to provide "module private" types and
utilities, but that doesn't scale to cases where a public header file
is needed and the new pass manager will exacerbate that. The pattern
I've adopted here is to use the namespace-cased-name of the core pass
(what would be a module if we had them) as a module-private namespace.
Then utility and other code can be declared and defined in this
namespace. At some point in the future, we could even have
(conditionally compiled) code that used modules features when
available to do the same basic thing.
- I've split the actual pass run method in two in order to expose
a private method usable by the old pass manager to wrap the new class
with a minimum of duplicated code. I actually looked at a bunch of
ways to automate or generate these, but they are all quite terrible
IMO. The fundamental need is to extract the set of analyses which need
to cross this interface boundary, and that will end up being too
unpredictable to effectively encapsulate IMO. This is also
a relatively small amount of boiler plate that will live a relatively
short time, so I'm not too worried about the fact that it is boiler
plate.
The rest of the patch is totally boring but results in a massive diff
(sorry). It just moves code around and removes or adds qualifiers to
reflect the new name and nesting structure.
Differential Revision: http://reviews.llvm.org/D12773
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247501 91177308-0d34-0410-b5e6-96231b3b80d8
We had asserts in PHINode::addIncoming to check that the value types matched
the type of the PHI, and that the associated BB was not null. These did not
catch, however, later uses of setIncomingValue and setIncomingBlock (which are
called by addIncoming as well). Moving the asserts to PHINode::setIncoming*
provides better coverage. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247492 91177308-0d34-0410-b5e6-96231b3b80d8
realignment should be forced.
With this commit, we can now force stack realignment when doing LTO and
do so on a per-function basis. Also, add a new cl::opt option
"stackrealign" to CommandFlags.h which is used to force stack
realignment via llc's command line.
Out-of-tree projects currently using -force-align-stack to force stack
realignment should make changes to attach the attribute to the functions
in the IR.
Differential Revision: http://reviews.llvm.org/D11814
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247450 91177308-0d34-0410-b5e6-96231b3b80d8
We used different conditions to determine if we should emit startproc vs
endproc. Use the same condition to ensure that they will always be
paired.
This fixes PR24374.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247435 91177308-0d34-0410-b5e6-96231b3b80d8
The rest of the EH pads are fine, since they have at most one label and
take fewer operands for the personality.
Old catchpad vs. new:
%5 = catchpad [i8* bitcast (i32 ()* @"\01?filt$0@0@main@@" to i8*)] to label %__except.ret.10 unwind label %catchendblock.9
-----
%5 = catchpad [i8* bitcast (i32 ()* @"\01?filt$0@0@main@@" to i8*)]
to label %__except.ret.10 unwind label %catchendblock.9
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247433 91177308-0d34-0410-b5e6-96231b3b80d8
