llvm-svn: 216155

llvm-svn: 216154

I'm adding new parameters to the function, and the existing
parameter with a default argument is found confusing.

llvm-svn: 216153

llvm-svn: 216152

This marks some of the localization test XFAIL on linux.
There has been some discussion on D4861 about doing this.
Please let me know if any of these tests for you on linux.

llvm-svn: 216151

This marks some of the localization test XFAIL on linux.
There has been some discussion on D4861 about doing this.
Please let me know if any of these tests for you on linux.

llvm-svn: 216150

In constant folding stage, "TRUNC" can't handle vector data type.

llvm-svn: 216149

This marks some of the localization test XFAIL on linux.
There has been some discussion on D4861 about doing this.
Please let me know if any of these tests for you on linux.

llvm-svn: 216148

llvm-svn: 216147

Both options control the final scope of atoms.

When -exported_symbols_list <file> is used, the file is parsed into one
symbol per line in the file.  Only those symbols will be exported (global)
in the final linked image.

The -keep_private_externs option is only used with -r mode. Normally, -r
mode reduces private extern (scopeLinkageUnit) symbols to non-external. But
add the -keep_private_externs option keeps them private external.

llvm-svn: 216146

Normally we mark all members of exported classes referenced to get them emitted.

However, MSVC doesn't do this for class templates that are implicitly specialized or
just have an explicit instantiation declaration. For such specializations, the members
are emitted when referenced.

The exception is the case when the dllexport attribute is propagated from a base class
to a base class template that doesn't have an explicit attribute: in this case all
methods of the base class template do get instantiated.

llvm-svn: 216145

advanced copy optimization.

This is the final step patch toward transforming:
udiv    r0, r0, r2
udiv    r1, r1, r3
vmov.32 d16[0], r0
vmov.32 d16[1], r1
vmov    r0, r1, d16
bx      lr

into:
udiv    r0, r0, r2
udiv    r1, r1, r3
bx      lr

Indeed, thanks to this patch, this optimization is able to look through
vmov.32 d16[0], r0
vmov.32 d16[1], r1

and is able to rewrite the following sequence:
vmov.32 d16[0], r0
vmov.32 d16[1], r1
vmov    r0, r1, d16

into simple generic GPR copies that the coalescer managed to remove.

<rdar://problem/12702965>

llvm-svn: 216144

target hook.

This patch teaches the compiler that:
dX = VSETLNi32 dY, rZ, imm
is the same as:
dX = INSERT_SUBREG dY, rZ, translateImmToSubIdx(imm)

<rdar://problem/12702965>

llvm-svn: 216143

Use the derived class in the macro instead, to make it unambigous where
the template is being instantiated.

llvm-svn: 216142

Only for Cortex-A57 and Cyclone for now, where it has shown wins.

llvm-svn: 216141

If we have a scalar reduction, we can increase the critical path length if the loop we're unrolling is inside another loop. Limit, by default to 2, so the critical path only gets increased by one reduction operation.

llvm-svn: 216140

This patch adds a new property: isInsertSubreg and the related target hooks:
TargetIntrInfo::getInsertSubregInputs and
TargetInstrInfo::getInsertSubregLikeInputs to specify that a target specific
instruction is a (kind of) INSERT_SUBREG.

The approach is similar to r215394.

<rdar://problem/12702965>

llvm-svn: 216139

On pre-v6 hardware, 'MOV lo, lo' gives undefined results, so such copies need to
be avoided. This patch trades simplicity for implementation time at the expense
of performance... As they say: correctness first, then performance.

See http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075998.html for a few
ideas on how to make this better.

llvm-svn: 216138

llvm-svn: 216137

advanced copy optimization.

This patch is a step toward transforming:
udiv	r0, r0, r2
udiv	r1, r1, r3
vmov.32	d16[0], r0
vmov.32	d16[1], r1
vmov	r0, r1, d16
bx	lr

into:
udiv	r0, r0, r2
udiv	r1, r1, r3
bx	lr

Indeed, thanks to this patch, this optimization is able to look through
vmov r0, r1, d16
but it does not understand yet
vmov.32 d16[0], r0
vmov.32 d16[1], r1

Comming patches will fix that and update the related test case.

<rdar://problem/12702965>

llvm-svn: 216136

New InstCombine pattern: (icmp ult/ule (A + C1), C3) | (icmp ult/ule (A + C2), C3)  to (icmp ult/ule ((A & ~(C1 ^ C2)) + max(C1, C2)), C3) under certain condition

llvm-svn: 216135

It makes no sense and can hide bugs. In particular, it lead
to left shift by 64 bits, which is an undefined behavior,
properly reported by UBSan.

llvm-svn: 216134

Also, make it slightly clearer what's being tested by only differentiating integer
literals based on their suffix, rather than using a very large constant.

llvm-svn: 216133

target hook.

This patch teaches the compiler that:
rX, rY = VMOVRRD dZ
is the same as:
rX = EXTRACT_SUBREG dZ, ssub_0
rY = EXTRACT_SUBREG dZ, ssub_1

<rdar://problem/12702965>

llvm-svn: 216132

This bug is reported by UBSan.

llvm-svn: 216131

This patch adds a new property: isExtractSubreg and the related target hooks:
TargetIntrInfo::getExtractSubregInputs and
TargetInstrInfo::getExtractSubregLikeInputs to specify that a target specific
instruction is a (kind of) EXTRACT_SUBREG.

The approach is similar to r215394.

<rdar://problem/12702965>

llvm-svn: 216130

Store TargetSelectionDAGInfo as a pointer instead of a reference:
getSelectionDAGInfo() may not be implemented for certain backends
(e.g. it's not currently implemented for R600).

This bug is reported by UBSan.

llvm-svn: 216129

llvm-svn: 216128

The default implementation is a no-op.  Targets should override this
with their own implementations.

llvm-svn: 216127

llvm-svn: 216126

This bug is reported by UBSan.

llvm-svn: 216125

llvm-svn: 216124

inside classes as static local variables and remove the static
ivars. Subclasses should use the accessor functions."

This change moved global statics to function local statics, but
forgot to make the locals static in the function, breaking all
platforms.  Furthermore, MSVC doesn't support thread-safe function
local statics, so any use of a function local static on non
primitive types is undefined behavior on MSVC.

Reverting due to the fact that it's broken on all platforms, but
would like to have a discussion about the thread-safety issue
before it goes back in.

llvm-svn: 216123

This is the one interesting aspect from:
   http://reviews.llvm.org/D4965

These hooks are useful for flavor specific processing, such as recording that
a DefinedAtom replaced a weak SharedLibraryAtom.

llvm-svn: 216122

Fix for PR20648 - http://llvm.org/bugs/show_bug.cgi?id=20648

This patch checks the operands of a vselect to see if all values are constants.
If yes, bail out of any further attempts to create a blend or shuffle because
SelectionDAGLegalize knows how to turn this kind of vselect into a single load.

This already happens for machines without SSE4.1, so the added checks just send
more targets down that path.

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

llvm-svn: 216121

llvm-svn: 216120

The goal of the patch is to implement section 3.2.3 of the AMD64 ABI
correctly.  The controlling sentence is, "The size of each argument gets
rounded up to eightbytes.  Therefore the stack will always be eightbyte
aligned." The equivalent sentence in the i386 ABI page 37 says, "At all
times, the stack pointer should point to a word-aligned area."  For both
architectures, the stack pointer is not being rounded up to the nearest
eightbyte or word between the last normal argument and the first
variadic argument.

Patch by Thomas Jablin!

llvm-svn: 216119

Both MachineLoopInfo and MachineDominatorTree may be null in ScheduleDAGMI
constructor call. It is undefined behavior to take references to these values.

This bug is reported by UBSan.

llvm-svn: 216118

Summary: This fixes http://llvm.org/bugs/show_bug.cgi?id=19530.
The problem is that X86ISelLowering erroneously thought the third call
was eligible for tail call elimination.
It would have been if it's return value was actually the one returned
by the calling function, but here that is not the case and
additional values are being returned.

Test Plan: Test case from the original bug report is included.

Reviewers: rafael

Reviewed By: rafael

Subscribers: rafael, llvm-commits

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

llvm-svn: 216117

This bug is reported by UBSan.

llvm-svn: 216116