x86 CPU detection for the X86 getHostCPUName too, and create a simple
getHostCPUName that returns "generic" for all else.

llvm-svn: 91240

about the potential use of these uninitialized members under certain conditions.

llvm-svn: 91239

llvm-svn: 91233

llvm-svn: 91232

llvm-svn: 91230

merging x >u 5 and x <s 20 because it's impossible to implement.

llvm-svn: 91228

llvm-svn: 91226

llvm-svn: 91223

No testcase yet - it seems we're exposing generic codegen bugs.

llvm-svn: 91221

llvm-svn: 91220

llvm-svn: 91219

MSVS2k8 doesn't define __i386__, hence all the CPU detection code was disabled.
Enable it by looking for _MSC_VER.

llvm-svn: 91217

llvm-svn: 91214

defined in the test, and I don't have time tonight to figure it out.

llvm-svn: 91209

supported by emitGlobals, but I don't have a test case for that.

llvm-svn: 91208

namespace llvm" by qualifying their implementations with ::llvm::.

llvm-svn: 91206

just issues an error for the moment. The front end won't yet generate these
intrinsics for ARM, so this is behind the scenes until complete.

llvm-svn: 91200

While scanning through the uses of an alloca, keep track of the current offset
relative to the start of the alloca, and check memory references to see if
the offset & size correspond to a component within the alloca.  This has the
nice benefit of unifying much of the code from isSafeUseOfAllocation,
isSafeElementUse, and isSafeUseOfBitCastedAllocation.  The code to rewrite
the uses of a promoted alloca, after it is determined to be safe, is
reorganized in the same way.

Also, when rewriting GEP instructions, mark them as "in-bounds" since all the
indices are known to be safe.

llvm-svn: 91184

a vector type.

llvm-svn: 91181

Based on the patch by Brian Lucas!

llvm-svn: 91175

branches only to a landing pad. Without this check, the compiler would go into
an infinite loop because the branch to a landing pad is an "abnormal" edge which
wasn't being taken into account.

This is the meat of that fix:

  if (!PrevBB.canFallThrough() && !MBB->BranchesToLandingPad(MBB)) {

The other stuff is simplification of the "branches to a landing pad" code.

llvm-svn: 91161

llvm-svn: 91159

llvm-svn: 91158

memory barrier instructions by definition have side effects. This prevents the post-RA scheduler from moving them around.

llvm-svn: 91150

llvm-svn: 91148

avoid spurious failures. This fixes PR5758.

llvm-svn: 91147

aggregate return values. This fixes PR5754.

llvm-svn: 91145

This is used in some weird cases like general dynamic TLS model.
This fixes PR5723

llvm-svn: 91144

llvm-svn: 91143

llvm-svn: 91140

This change removes the DefaultConstructible
and CopyAssignable constraints on the template
parameter T (the first one).

The second template parameter (R) is defaulted to be
identical to the first and controls the result type.
By specifying it to be (const T&) additionally the
CopyConstructible constraint on T can be removed.

This allows to use StringSwitch e.g. for llvm::Constant
instances.

Regarding the other review feedback regarding performance
because of taking pointers, this class should be completely
optimizable like before, since all methods are inline and
the pointer dereferencing and result value caching should be
possible behind the scenes by the "as-if" rule.

llvm-svn: 91123

build bots.

llvm-svn: 91113

has the 'nest' attribute.

llvm-svn: 91109

llvm-svn: 91105

llvm-svn: 91104

llvm-svn: 91103

- Loosen the restrictions when checking of it branches to a landing pad.
- Make the loop more efficient by checking the '.insert' return value.
- Do cheaper checks first.

llvm-svn: 91101

more than one successor. Normally, these extra successors are dead. However,
some of them may branch to exception handling landing pads. If we remove those
successors, then the landing pads could go away if all predecessors to it are
removed. Before, it was checking if the direct successor was the landing
pad. But it could be the result of jumping through multiple basic blocks to get
to it. If we were to only check for the existence of an EH_LABEL in the basic
block and not remove successors if it's in there, then it could stop actually
dead basic blocks from being removed.

llvm-svn: 91092

llvm-svn: 91090

llvm-svn: 91087