llvm-svn: 232995

llvm-svn: 232994

llvm-svn: 232993

Don't use a separate table for compares anymore,
and use the same VOP2_REV class.

llvm-svn: 232992

Also don't count the class instructions as isCompare anymore.

llvm-svn: 232991

These are already set in the base class for the instruction.

llvm-svn: 232990

llvm-svn: 232989

This enables very common cases to switch to the
smaller encoding.

All of the standard LLVM canonicalizations of comparisons
are the opposite of what we want. Compares with constants
are moved to the RHS, but the first operand can be an inline
immediate, literal constant, or SGPR using the 32-bit VOPC
encoding.

There are additional bad canonicalizations that should
also be fixed, such as canonicalizing ge x, k to gt x, (k + 1)
if this makes k no longer an inline immediate value.

llvm-svn: 232988

Use VOPCX_F64 to not need the let Defs = [EXEC]

llvm-svn: 232987

It isn't used, and these will probably never be directly selected.

llvm-svn: 232986

See detailed discussion at

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140915/235418.html

and r217907, r217948:

 http://llvm.org/viewvc/llvm-project?view=revision&revision=217907
 http://llvm.org/viewvc/llvm-project?view=revision&revision=217948

llvm-svn: 232982

NFC.

llvm-svn: 232981

Also reorder includes a bit, NFC.

llvm-svn: 232980

NFC.

llvm-svn: 232976

Patch by Geoff Berry<gberry@codeaurora.org>.

llvm-svn: 232967

This change is incorrect since it converts double rounding into single rounding,
which can produce different results. Instead this optimization will be done by
modifying Clang's codegen to not produce double rounding in the first place.

This reverts commit r232954.

llvm-svn: 232962

Patch by Richard (legalize@xmission.com)

Differential Revision: http://reviews.llvm.org/D8521

llvm-svn: 232961

Anton tried this 5 years ago but it was reverted due to extra VMOVs
being emitted. This can be easily fixed with a liberal application
of patterns - matching loads/stores and extractelts.

llvm-svn: 232958

This function assumed that SMRD instructions always have immediate
offsets, which is not always the case.

llvm-svn: 232957

Patch by Richard
http://reviews.llvm.org/D8523

llvm-svn: 232955

Specifically when the conversion is done in two steps, f16 -> f32 -> f64.

For example:

%1 = tail call float @llvm.convert.from.fp16.f32(i16 %0)
%conv = fpext float %1 to double

to:

vcvtb.f64.f16

llvm-svn: 232954

NFC.

llvm-svn: 232949

NFC.

llvm-svn: 232944

Fixing sign extension in makeLibCall for MIPS64. In MIPS64 architecture all
32 bit arguments (int, unsigned int, float 32 (soft float)) must be sign
extended. This fixes test "MultiSource/Applications/oggenc/".

Patch by Strahinja Petrovic.

Differential Revision: http://reviews.llvm.org/D7791

llvm-svn: 232943

Summary:
But still handle them the same way since I don't know how they differ on
this target.

Clang also has code for 'Ump', 'Utf', 'Usa', and 'Ush' but calls
llvm_unreachable() on this code path so they are not converted to a
constraint id at the moment.

No functional change intended.

Reviewers: t.p.northover

Subscribers: aemerson, llvm-commits

Differential Revision: http://reviews.llvm.org/D8177

llvm-svn: 232941

Because the operands of a vector SETCC node can be of a different type from the
result (and often are), it can happen that even if we'd prefer to widen the
result type of the SETCC, the operands have been split instead. In this case,
the SETCC result also must be split. This mirrors what is done in
WidenVecRes_SELECT, and should be NFC elsewhere because if the operands are not
widened the following calls to GetWidenedVector will assert (which is what was
happening in the test case).

llvm-svn: 232935

llvm-svn: 232929

llvm-svn: 232927

llvm-svn: 232923

It's not intended to be polymorphically deleted. Make FoldingSet
and ContextualFoldingSet final to avoid noise from -Wnon-virtual-dtor.

No functional change intended.

llvm-svn: 232922

- was reporting 'warning C4715: 'getType32' : not all control paths return a value'

llvm-svn: 232913

llvm-svn: 232903

strchr("123!", C) != nullptr is a common pattern to check if C is one
of 1, 2, 3 or !. If the largest element of the string is smaller than
the target's register size we can easily create a bitfield and just
do a simple test for set membership.

int foo(char C) { return strchr("123!", C) != nullptr; } now becomes

	cmpl	$64, %edi ## range check
	sbbb	%al, %al
	movabsq	$0xE000200000001, %rcx
	btq	%rdi, %rcx ## bit test
	sbbb	%cl, %cl
	andb	%al, %cl ## and the two conditions
	andb	$1, %cl
	movzbl	%cl, %eax ## returning an int
	ret

(imho the backend should expand this into a series of branches, but
that's a different story)

The code is currently limited to bit fields that fit in a register, so
usually 64 or 32 bits. Sadly, this misses anything using alpha chars
or {}. This could be fixed by just emitting a i128 bit field, but that
can generate really ugly code so we have to find a better way. To some
degree this is also recreating switch lowering logic, but we can't
simply emit a switch instruction and thus change the CFG within
instcombine.

llvm-svn: 232902

This is just memchr(x, y, 0) -> nullptr and constant folding.

llvm-svn: 232896

Currently this is only used to tweak the backend's memcpy inlining
heuristics, testing that isn't very helpful. A real test case will
follow in the next commit, where this behavior would cause a real
miscompilation.

llvm-svn: 232895

r216771 introduced a change to MemoryDependenceAnalysis that allowed it
to reason about acquire/release operations.  However, this change does
not ensure that the acquire/release operations pair.  Unfortunately,
this leads to miscompiles as we won't see an acquire load as properly
memory effecting.  This largely reverts r216771.

This fixes PR22708.

llvm-svn: 232889

TargetMachine::getSubtargetImpl routines.

This keeps the target independent code free of bare subtarget
calls while the remainder of the backends are migrated, or not
if they don't wish to support per-function subtargets as would
be needed for function multiversioning or LTO of disparate
cpu subarchitecture types, e.g.

clang -msse4.2 -c foo.c -emit-llvm -o foo.bc
clang -c bar.c -emit-llvm -o bar.bc
llvm-link foo.bc bar.bc -o baz.bc
llc baz.bc

and get appropriate code for what the command lines requested.

llvm-svn: 232885

of this add a test that shows we can generate code for functions
that specifically enable a subtarget feature.

llvm-svn: 232884

of this add a test that shows we can generate code with
for functions that differ by subtarget feature.

llvm-svn: 232882

bare target machine in preparation for the TargetMachine bare
getSubtarget/getSubtargetImpl calls going away.

llvm-svn: 232880