llvm-svn: 200251

Also update the comment, since it actually produces a
select (setcc) instead of select_cc.

It was checking and using the setcc result type for the
type of the sext, instead of the type of the compared items.

In my problem case, the sext was to i32 and was used as the setcc type,
but the expected type was i64.

No test since I haven't been able to hit the problem with
this on any in-tree targets.

llvm-svn: 200249

Summary:
This commit gives an address mode to the PLD instruction. We
were getting an assertion failure in the frame lowering code
because we had code that was doing a pld of a stack allocated
address. The frame lowering was checking the address mode and
then asserting because pld had none defined.

This commit fixes pld for arm mode. There was a previous fix for
thumb mode in a separate commit. The commit for thumb mode
added a test in a separate file because it would otherwise fail
for arm. This commit moves the thumb test back into the prefetch.ll
file and adds the corresponding arm test.

Differential Revision: http://llvm-reviews.chandlerc.com/D2622

llvm-svn: 200248

ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case

Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero.

llvm-svn: 200247

This change modifies the 'A' command handler's launch code to launch
with LaunchProcess (). The net effect is that the default process
monitoring that LaunchProcess () adds will kick in, allowing the
GDBRemoteCommunicationServer to be able to reap processes started with
this facility correctly. Later, in the case of lldb-gdbserver, we'll
also have the proper process monitoring going on to really debug the
inferior process.

llvm-svn: 200246

llvm-svn: 200245

llvm-svn: 200244

This failed the ms-intrin.cpp test.

This reverts commit r200237.

This also comments out the _setjmpex declaration for now so that
intrin.h will work on x64 targets.

llvm-svn: 200243

This reverts commit r200233.

The test required a registered ARM target, it was testing LLVM's
generated assembly, and it should have been an IRGen test.

llvm-svn: 200242

llvm-svn: 200240

Adds an implementation for _InterlockedCompareExchangePointer() and
__faststorefence().

Patch by David Ziman!

llvm-svn: 200239

parimary class and in mrr mode, assume property's default
memory attribute (assign) and to prevent a bogus warning.
// rdar://15859862

llvm-svn: 200238

This fixes an error on our _setjmpex declaration for 64-bit code and
allows us to declare _setjmp for 32-bit code.

llvm-svn: 200237

llvm-svn: 200236

This avoids warnings visible with -Wsystem-headers.

llvm-svn: 200235

This patch teaches the DAGCombiner how to fold a sext/aext/zext dag node when
the operand in input is a build vector of constants (or UNDEFs).

The inability to fold a sext/zext of a constant build_vector was the root
cause of some pcg bugs affecting vselect expansion on x86-64 with AVX support.

Before this change, the DAGCombiner only knew how to fold a sext/zext/aext of a
ConstantSDNode.

llvm-svn: 200234

llvm-svn: 200233

Implement __builtin_eh_return_data_regno()

llvm-svn: 200231

(comment without a decl).

I think this can not happen during normal compilation with -Wdocumentation,
only while using Clang APIs to parse comments outside of a source file.

Based on a patch by Olivier Goffart.

llvm-svn: 200230

This isn't C4800, it's C4805.  MSVC says this is unsafe, but it
generates correct code.

llvm-svn: 200229

llvm-svn: 200228

This commit allows LLVM MC to process .cfi_startproc directives when
they are followed by an additional `simple' identifier. This signals to
elide the emission of target specific CFI instructions that would
normally occur initially.

This fixes PR16587.

Differential Revision: http://llvm-reviews.chandlerc.com/D2624

llvm-svn: 200227

This patch addresses a bug where in a multi-threaded program a new
signal from the inferior may be received before all group-stop
messages from an earlier signal have been handled.

Patch by Andrew MacPherson

llvm-svn: 200226

This does not only seem helpful for Polly, but it should help in general to
further reduce bugs.

llvm-svn: 200225

llvm-svn: 200224

llvm-svn: 200223

llvm-svn: 200222

llvm-svn: 200221

Reiterating: llvm-gcc is dead since a long time.
llvm-svn: 200220

cold loops as-if they were being optimized for size.

Nothing fancy here. Simply test case included. The nice thing is that we
can now incrementally build on top of this to drive other heuristics.
All of the infrastructure work is done to get the profile information
into this layer.

The remaining work necessary to make this a fully general purpose loop
unroller for very hot loops is to make it a fully general purpose loop
unroller. Things I know of but am not going to have time to benchmark
and fix in the immediate future:

1) Don't disable the entire pass when the target is lacking vector
   registers. This really doesn't make any sense any more.
2) Teach the unroller at least and the vectorizer potentially to handle
   non-if-converted loops. This is trivial for the unroller but hard for
   the vectorizer.
3) Compute the relative hotness of the loop and thread that down to the
   various places that make cost tradeoffs (very likely only the
   unroller makes sense here, and then only when dealing with loops that
   are small enough for unrolling to not completely blow out the LSD).

I'm still dubious how useful hotness information will be. So far, my
experiments show that if we can get the correct logic for determining
when unrolling actually helps performance, the code size impact is
completely unimportant and we can unroll in all cases. But at least
we'll no longer burn code size on cold code.

One somewhat unrelated idea that I've had forever but not had time to
implement: mark all functions which are only reachable via the global
constructors rigging in the module as optsize. This would also decrease
the impact of any more aggressive heuristics here on code size.

llvm-svn: 200219

Insert before the terminating instruction of the dominating block instead.

llvm-svn: 200218

[sanitizer] revert r200197: the buggy kernel (https://bugzilla.kernel.org/show_bug.cgi?id=67651) is almost unusable with asan even with this workaround (too slow), so this workaround makes no sense. The asan/msan bootstrap bot was changed to use a non-buggy kernel

llvm-svn: 200217

llvm-svn: 200216

to stabilize a test that really is trying to test generic behavior and
not a specific target's behavior.

llvm-svn: 200215

object and fewer pointless variables.

Also, add a clarifying comment and a FIXME because the code which
disables *all* vectorization if we can't use implicit floating point
instructions just makes no sense at all.

llvm-svn: 200214

powers of two. This is essentially always the correct thing given the
impact on alignment, scaling factors that can be used in addressing
modes, etc. Also, fix the management of the unroll vs. small loop cost
to more accurately model things with this world.

Enhance a test case to actually exercise more of the unroll machinery if
using synthetic constants rather than a specific target model. Before
this change, with the added flags this test will unroll 3 times instead
of either 2 or 4 (the two sensible answers).

While I don't expect this to make a huge difference, if there are lots
of loops sitting right on the edge of hitting the 'small unroll' factor,
they might change behavior. However, I've benchmarked moving the small
loop cost up and down in many various ways and by a huge factor (2x)
without seeing more than 0.2% code size growth. Small adjustments such
as the series that led up here have led to about 1% improvement on some
benchmarks, but it is very close to the noise floor so I mostly checked
that nothing regressed. Let me know if you see bad behavior on other
targets but I don't expect this to be a sufficiently dramatic change to
trigger anything.

llvm-svn: 200213

with the unrolling behavior in the loop vectorizer. No functionality
changed at this point.

These are a bit hack-y, but talking with Hal, there doesn't seem to be
a cleaner way to easily experiment with different thresholds here and he
was also interested in them so I wanted to commit them. Suggestions for
improvement are very welcome here.

llvm-svn: 200212

number of vector registers rather than toggling between vector and
scalar register number based on VF. I don't have a test case as
I spotted this by inspection and on X86 it only makes a difference if
your target is lacking SSE and thus has *no* vector registers.

If someone wants to add a test case for this for ARM or somewhere else
where this is more significant, that would be awesome.

Also made the variable name a bit more sensible while I'm here.

llvm-svn: 200211

Fix crasher introduced in r200203 and caught by a libc++ buildbot. Don't assume that getMulExpr returns a SCEVMulExpr, it may have simplified it to something else!

llvm-svn: 200210

llvm-svn: 200209