llvm-svn: 129000

llvm-svn: 128957

As a result, I had to remove a c++ version of a clang
test which requires more scrutiny on my part.

llvm-svn: 128950

llvm-svn: 128948

targets) when load/store results in multiple instructions.
// rdar://8808439

llvm-svn: 128937

llvm-svn: 128928

llvm-svn: 128921

llvm-svn: 128915

developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.

Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.

llvm-svn: 128911

llvm-svn: 128908

llvm-svn: 128893

Does anyone want to buy me a new brain?

llvm-svn: 128890

llvm-svn: 128866

llvm-svn: 128857

llvm-svn: 128855

llvm-svn: 128842

CharUnits. No change in functionality intended.

llvm-svn: 128776

change in functionality intended.

llvm-svn: 128773

dumpLayout(). No change in functionality intended.

llvm-svn: 128771

change in functionality intended.

llvm-svn: 128770

functionality intended.

llvm-svn: 128756

CharUnits. No change in functionality intended.

llvm-svn: 128754

functionality intended.

llvm-svn: 128753

No change in functionality intended.

llvm-svn: 128752

llvm-svn: 128725

that of the array element type.

llvm-svn: 128698

arrays by propagating", it's breaking test in ways I don't understand yet.

llvm-svn: 128693

the array alignment to the array access.
 - This is more or less the best we can do without having alignment present in
   the type system, but is a long way from truly matching how GCC handles this.

llvm-svn: 128691

llvm-svn: 128621

__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.

Found by inspection.

Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.

llvm-svn: 128618

change.

llvm-svn: 128608

llvm-svn: 128607

llvm-svn: 128605

VCallAndVBaseOffsetBuilder::getCurrentOffsetOffset() to CharUnits. No change
in functionality intended.

llvm-svn: 128603

VCallAndVBaseOffsetBuilder::AddVBaseOffsets() to CharUnits. No change in
functionality intended.

llvm-svn: 128600

constructor to CharUnits. No change in functionality intended.

llvm-svn: 128598

VCallAndVBaseOffsetBuilder::AddVCallAndVBaseOffsets() to
CharUnits. No change in functionality intended.

llvm-svn: 128596

llvm-svn: 128590

for prperty reference types. // rdar://9208606.

llvm-svn: 128551

PHINode::Create() giving the (known or expected) number of operands.

llvm-svn: 128538