llvm-svn: 84431

llvm-svn: 84428

llvm-svn: 84427

llvm-svn: 84426

llvm-svn: 84425

stack slots and giving them different PseudoSourceValue's did not fix the
problem of post-alloc scheduling miscompiling llvm itself.
- Apply Dan's conservative workaround by assuming any non fixed stack slots can
alias other memory locations. This means a load from spill slot #1 cannot 
move above a store of spill slot #2. 
- Enable post-alloc scheduling for x86 at optimization leverl Default and above.

llvm-svn: 84424

llvm-svn: 84423

llvm-svn: 84422

llvm-svn: 84421

llvm-svn: 84420

llvm-svn: 84419

llvm-svn: 84418

llvm-svn: 84417

The AuroraUX toolchain has conflicting wchar_t between the system stdlib.h header and the clang stddef.h header where clang was defining as int where we use long.

llvm-svn: 84416

llvm-svn: 84415

llvm-svn: 84414

llvm-svn: 84413

TemplateTypeParmType with the substituted type directly;  instead, replace it
with a SubstTemplateTypeParmType which will note that the type was originally
written as a template type parameter.  This makes it reasonable to preserve
source information even through template substitution.

Also define the new SubstTemplateTypeParmType class, obviously.

For consistency with current behavior, we stringize these types as if they
were the underlying type.  I'm not sure this is the right thing to do.
At any rate, I paled at adding yet another clause to the don't-desugar 'if'
statement, so I extracted a function to do it.  The new function also does
The Right Thing more often, I think:  e.g. if we have a chain of typedefs
leading to a vector type, we will now desugar all but the last one.

llvm-svn: 84412

llvm-svn: 84411

llvm-svn: 84410

llvm-svn: 84409

llvm-svn: 84408

llvm-svn: 84407

llvm-svn: 84406

llvm-svn: 84405

instructions.

llvm-svn: 84404

llvm-svn: 84403

transform, which isn't happening yet.

llvm-svn: 84402

llvm-svn: 84401

llvm-svn: 84400

llvm-svn: 84399

llvm-svn: 84398

accessible through opt.  Patch by Tobias Grosser!

llvm-svn: 84397

llvm-svn: 84396

llvm-svn: 84395

llvm-svn: 84394

llvm-svn: 84393

 - Really this should be simplified by the FIXME above, but I'm too deep in DFS.

llvm-svn: 84392

llvm-svn: 84391

 - I have this crazy dream that one day someone will invent a miraculous tool so
   that developers, instead of hand optimizing their source code to obscure its
   intent and decrease its maleability, will instead write what they mean, and
   this strange and wonderful tool -- which I imagine would be called something
   fancy sounding like "an optimizing compiler" -- will make their code fast
   *for* them. With all the saved time, developers could maybe even focus on
   making the magic "optimizing compiler" better!!

 - No intended functionality change, all though I expect the universe to mock me
   for snarkiness.

llvm-svn: 84390