llvm-svn: 65274

Do not consider MMX_MOVD64rr a move instructions. The source register is in GR32, the destination is VR64. They are not compatible.

llvm-svn: 65273

llvm-svn: 65270

Fix regression in naming convention derivation: a method only follows the copy 'rule' if it doesn't already start with 'init', etc.

llvm-svn: 65269

Only try to sink immediate when TLI is not null. It needs to check if immediate would fit in target addressing field.

llvm-svn: 65268

llvm-svn: 65267

as byval. Otherwise LLVM will have its own opinion about where to put
things.

We now pass all gcc dg.compat tests on x86_64.

llvm-svn: 65266

helper isConstantInitializer) to check whether an initializer is 
constant.  This passes tests, but it's possible that it'll cause 
regressions with real-world code.

Future work:
1. The diagnostics obtained this way are lower quality at the moment; 
some work both here and in Evaluate is needed for accurate diagnostics.
2. We probably need some extra code when we're in -pedantic mode so we 
can strictly enforce the rules in C99 6.6p7.
3. Dead code cleanup (this should wait until after 2, because we might 
want to re-use some of the code).

llvm-svn: 65265

about these much but <2 x i16> shows up in the gcc test suite.

llvm-svn: 65264

of sizes. Turns out we don't care very much about vector types that
don't map to the hardware.

llvm-svn: 65263

Also, make sure to pass <1 x i64> as i64 (not <1 x i64>, which doesn't
quite work yet in the backend).

llvm-svn: 65262

I know, these follow the exact same rules as pointers, so I just made 
them use the same codepath.  Someone more familiar with ObjC should 
double-check this, though.

llvm-svn: 65261

partially done in r65258.)

llvm-svn: 65260

CodeGen.  I'm not sure whether this actually makes any visible 
difference, but it's better to be consistent anyway.

llvm-svn: 65259

PR3254 and part of PR3433.

The isICE changes are necessary to keep the computed results 
consistent with Evaluate.

llvm-svn: 65258

llvm-svn: 65257

llvm-svn: 65256

llvm-svn: 65255

compilation results on failures.

llvm-svn: 65254

required to actually be an error for correctness.  The attached testcase 
now gives an error instead of mysteriously crashing.

Now, it's possible we actually want to support the given usage, but I 
haven't looked at the relevant code closely.

llvm-svn: 65253

llvm-svn: 65252

llvm-svn: 65251

llvm-svn: 65250

llvm-svn: 65249

This is necessary 'plumbing' to fix <rdar://problem/6497631> Message lookup is sometimes different than gcc's.

llvm-svn: 65248

<prefix>/Headers, gross).

llvm-svn: 65247

load(bitcast(char[4] to i32*)) evaluation.

llvm-svn: 65246

value/definition/origin of FOO.

llvm-svn: 65245

Found while researching <rdar://problem/6497631> Message lookup is sometimes different than gcc's.

Will never be seen in user code. Needed to pass dejagnu testsuite.

llvm-svn: 65244

llvm-svn: 65243

stuff is mostly done.  Move BlockHasCopyDispose up.

llvm-svn: 65242

llvm-svn: 65241

variable (objc2 gc specific).

llvm-svn: 65240

llvm-svn: 65239

as __weak (objc2 gc specific).

llvm-svn: 65238

llvm-svn: 65237

Add version of StringsEqualNoCase that takes two null-terminated C-strings and compares up to 'len' characters.  I tend to screw up string comparison functions, so anyone who is interested please review this\!

llvm-svn: 65236

llvm-svn: 65235

expr; hilarity ensued.
 - PR3640.

llvm-svn: 65234

Should clang have a config.h or should we use the config.h of llvm or using the preprocessor is OK?  I did a quick fix here, but having a guideline on how to handle non portable function would be great (or ask ted to stop breaking the windows build :)).

llvm-svn: 65233