return StringSwitch<int>(Flags)
.Case("g", 0x1)
.Case("nzcvq", 0x2)
.Case("nzcvqg", 0x3)
.Default(-1);
...
// The _g and _nzcvqg versions are only valid if the DSP extension is
// available.
if (!Subtarget->hasThumb2DSP() && (Mask & 0x2))
return -1;
ARMARM confirms that the comment is right, and the code was wrong.
llvm-svn: 244029
In r242277, I updated the MachineCombiner to work with itineraries, but I
missed a call that is scheduling-model-only (the opcode-only form of
computeInstrLatency). Using the form that takes an MI* allows this to work with
itineraries (and should be NFC for subtargets with scheduling models).
llvm-svn: 244020
Previously we kept going on partly corrupted input, which might result
in garbage being printed, or even worse, random crashes.
Rafael mentioned that this is the GNU behavior as well, but after some
discussion we both agreed it's probably better to emit a reasonable
error message and exit. As a side-effect of this commit, now we don't
rely on global state for error codes anymore. objdump was the last tool
in the toolchain which needed to be converted. Hopefully the old behavior
won't sneak into the tree again.
llvm-svn: 244019
For example of mingw-w64-g++-4.8.1,
llvm/unittests/ADT/ArrayRefTest.cpp: In member function 'virtual void {anonymous}::ArrayRefTest_AllocatorCopy_Test::TestBody()':
llvm/unittests/ADT/ArrayRefTest.cpp:56:40: internal compiler error: in count_type_elements, at expr.c:5523
} Array3Src[] = {{"hello"}, {"world"}};
^
Please submit a full bug report,
with preprocessed source if appropriate.
llvm-svn: 244017
As documented in the LLVM Coding Standards, indeed MSVC incorrectly asserts
on this in Debug mode. This happens when building clang with Visual C++ and
-triple i686-pc-windows-gnu on these clang regression tests:
clang/test/CodeGen/2011-03-08-ZeroFieldUnionInitializer.c
clang/test/CodeGen/empty-union-init.c
llvm-svn: 243996
Create wrapper methods in the Function class for the OptimizeForSize and MinSize
attributes. We want to hide the logic of "or'ing" them together when optimizing
just for size (-Os).
Currently, we are not consistent about this and rely on a front-end to always set
OptimizeForSize (-Os) if MinSize (-Oz) is on. Thus, there are 18 FIXME changes here
that should be added as follow-on patches with regression tests.
This patch is NFC-intended: it just replaces existing direct accesses of the attributes
by the equivalent wrapper call.
Differential Revision: http://reviews.llvm.org/D11734
llvm-svn: 243994
In the commentary for D11660, I wasn't sure if it was alright to create new
integer machine instructions without also creating the implicit EFLAGS operand.
From what I can see, the implicit operand is always created by the MachineInstrBuilder
based on the instruction type, so we don't have to do that explicitly. However, in
reviewing the debug output, I noticed that the operand was not marked as 'dead'.
The machine combiner should do that to preserve future optimization opportunities
that may be checking for that dead EFLAGS operand themselves.
Differential Revision: http://reviews.llvm.org/D11696
llvm-svn: 243990
It's not valid code (maybe it can be made valid, but I'm not sure how).
To trigger the crash fixed in r243987 requires a friend function with
more than four template parameter lists. With this test we have at least
some coverage.
llvm-svn: 243989
SmallVector::set_size does not reallocate the vector. Sadly I have no
idea how to test this. The vector never has more than one member in all
of the regression tests.
Found by inspection.
llvm-svn: 243987
Summary:
Previously, we would check whether the target is supported or not, only in
fastSelectInstruction(). This means that 64-bit targets could use FastISel too.
We fix this by checking every overridden method of the FastISel class and
by falling back to SelectionDAG if the target isn't supported. This change
should have been committed along with r243638, but somehow I missed it.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11755
llvm-svn: 243986
It introduced two regressions on 64-bit big-endian targets running under N32
(MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4, and
MultiSource/Applications/kimwitu++/kc) The issue is that on 64-bit targets
comparisons such as BEQ compare the whole GPR64 but incorrectly tell the
instruction selector that they operate on GPR32's. This leads to the
elimination of i32->i64 extensions that are actually required by
comparisons to work correctly.
There's currently a patch under review that fixes this problem.
llvm-svn: 243984
Aaron Ballman