result is dead.  This is required for my next patch to not
regress the testsuite.

llvm-svn: 122181

llvm-svn: 122180

the old thing end up on the instcombine worklist.  Not doing this
can cause an extra top-level iteration of instcombine, burning
compile time.

llvm-svn: 122179

sadd formed is half the size of the original type. We can
now compile this into a sadd.i8:

unsigned char X(char a, char b) {
  int res = a+b;
  if ((unsigned )(res+128) > 255U)
    abort();
  return res;
}

llvm-svn: 122178

checking to see if the high bits of the original add result were dead.
Inserting a smaller add and zexting back to that size is not good enough.

This is likely to be the fix for 8816.

llvm-svn: 122177

alternative register allocator that does not require LiveIntervals by specifying
it on the command-line for a target that has StrongPHIElimination enabled by
default.

These checks are pretty meaningless anyways, since StrongPHIElimination and
PHIElimination are never used at the same time.

llvm-svn: 122176

profitable (or safe) to promote code when the add-with-constant
has other uses.

llvm-svn: 122175

helper function, clean up comments, and reduce indentation.
No functionality change.

llvm-svn: 122174

example:
struct __declspec(uuid("6d5140c1-7436-11ce-8034-00aa006009fa"))
test { };

llvm-svn: 122173

which doesn't affect the memory address being promoted.

llvm-svn: 122172

does not make the alias set for that pointer volatile, just stores
*to* the pointer.

llvm-svn: 122171

isel is *required* to split the edge.  PHI values get evaluated
on the edge, not in their predecessor block.

llvm-svn: 122170

llvm-svn: 122169

llvm-svn: 122168

llvm-svn: 122167

a shell would interpret it. A few examples that we now handle correctly

INPUT: "Hello "world
OUTPUT: "Hello World"

INPUT: "Hello "' World'
OUTPUT: "Hello World"

INPUT: Hello" World"
OUTPUT: "Hello World"

This broke the setting of dictionary values for the "settings set" command
for things like:

(lldb) settings set target.process.env-vars ["MY_ENV_VAR"]=YES

since we would drop the quotes. I fixed the user settings controller to use
a regular expression so it can accept any of the following inputs for
dictionary setting:

settings set target.process.env-vars ["MY_ENV_VAR"]=YES
settings set target.process.env-vars [MY_ENV_VAR]=YES
settings set target.process.env-vars MY_ENV_VAR=YES

We might want to eventually drop the first two syntaxes, but I won't make
that decision right now.

This allows more natural setting of the envirorment variables:

settings set target.process.env-vars MY_ENV_VAR=YES ABC=DEF CWD=/tmp

llvm-svn: 122166

llvm-svn: 122165

which have trapping constant exprs in them due to PHI nodes.
Eliminating them can cause the constant expr to be evalutated
on new paths if the input edges are critical.

llvm-svn: 122164

is enabled.

llvm-svn: 122163

llvm-svn: 122162

create a temporary object for it.

llvm-svn: 122161

llvm-svn: 122160

llvm-svn: 122159

llvm-svn: 122158

llvm-svn: 122157

llvm-svn: 122156

It turns out that ppc backend has really weird interdependencies
over different hooks and all stuff is fragile wrt small changes.
This should fix PR8749

llvm-svn: 122155

Just rename the functions, relying on matching a instruction that has the same name as a symbol is way too fragile.

llvm-svn: 122154

llvm-svn: 122153

llvm-svn: 122152

This fixed 8615.

llvm-svn: 122150

the buildbots.

llvm-svn: 122149

llvm-svn: 122148

llvm-svn: 122147

llvm-svn: 122146

of two symbols in the same fragment.

llvm-svn: 122145

llvm-svn: 122144

llvm-svn: 122143

llvm-svn: 122142

llvm-svn: 122141