likely a result of copy/paste.

llvm-svn: 130640

traits where possible. For the rest, group them and add some
documentation regarding their origins.

No functionality change intended.

llvm-svn: 130639

a single pattern for implementing each.

llvm-svn: 130638

-fno-dwarf2-cfi-asm. Implement the same behavior.

llvm-svn: 130637

Add a triple to this test, otherwise it fails under MSVC because wchar_t is unsigned with the i686-pc-win32 triple.

llvm-svn: 130636

llvm-svn: 130635

for all symbol differences and can drop the old EmitPCRelSymbolValue
method.

This also make getExprForFDESymbol on ELF equal to the one on MachO, and it
can be made non-virtual.

llvm-svn: 130634

stop considering whether I can compress them. :)

llvm-svn: 130633

devirtualize Decl (because bits can't get laid out in base
classes if the base is POD).

llvm-svn: 130632

llvm-svn: 130631

SubstTemplateTypeParmType to be 'getIdentifier' instead of 'getName' as
it returns an identifier. This makes them more consistent with the
NamedDecl interface.

Also, switch back to using this interface to acquire the indentifier in
TypePrinter.cpp. I missed this in r130628.

llvm-svn: 130629

accompanying fixes to make it work today.

The core of this patch is to provide a link from a TemplateTypeParmType
back to the TemplateTypeParmDecl node which declared it. This in turn
provides much more precise information about the type, where it came
from, and how it functions for AST consumers.

To make the patch work almost a year after its first attempt, it needed
serialization support, and it now retains the old getName() interface.
Finally, it requires us to not attempt to instantiate the type in an
unsupported friend decl -- specifically those coming from template
friend decls but which refer to a specific type through a dependent
name.

A cleaner representation of the last item would be to build
FriendTemplateDecl nodes for these, storing their template parameters
etc, and to perform proper instantation of them like any other template
declaration. They can still be flagged as unsupported for the purpose of
access checking, etc.

This passed an asserts-enabled bootstrap for me, and the reduced test
case mentioned in the original review thread no longer causes issues,
likely fixed at somewhere amidst the 24k revisions that have elapsed.

llvm-svn: 130628

less agressive about disabling cfi on linux :-(

llvm-svn: 130627

less agressive about disabling cfi on linux :-(

llvm-svn: 130626

after folding ADD32ri to ADD32mi, so don't do that.

This only happens when the greedy register allocator gets itself in trouble and
spills %vreg9 here:

16L             %vreg9<def> = MOVPC32r 0, %ESP<imp-use>; GR32:%vreg9
48L             %vreg9<def> = ADD32ri %vreg9, <es:_GLOBAL_OFFSET_TABLE_>[TF=1], %EFLAGS<imp-def,dead>; GR32:%vreg9

That should never happen, the live range should be split instead.

llvm-svn: 130625

llvm-svn: 130624

Currently the output should be almost identical to the one produced by CodeGen
to make the transition easier.

The only two differences I know of are:

* Some files get an extra advance loc of size 0. This will be fixed when
relaxations are enabled.
* The optimization of declaring an EH symbol as an external variable is not
implemented. This is a subset of adding the nounwind attribute, so we if really
this at -O0 we should probably do it at the IL level.

llvm-svn: 130623

llvm-svn: 130622

llvm-svn: 130621

wchar_t is an unsigned type.

llvm-svn: 130620

range covers the entire block.

The live range can't be terminated at a random instruction.

llvm-svn: 130619

particular, make sure to handle WCHAR_MIN correctly.

llvm-svn: 130618

llvm-svn: 130617

llvm-svn: 130616

This obviously helps a lot if the division would be turned into a libcall
(think i64 udiv on i386), but div is also one of the few remaining instructions
on modern CPUs that become more expensive when the bitwidth gets bigger.

This also helps register pressure on i386 when dividing chars, divb needs
two 8-bit parts of a 16 bit register as input where divl uses two registers.

int foo(unsigned char a) { return a/10; }
int bar(unsigned char a, unsigned char b) { return a/b; }

compiles into (x86_64)
_foo:
  imull $205, %edi, %eax
  shrl  $11, %eax
  ret
_bar:
  movzbl        %dil, %eax
  divb  %sil, %al
  movzbl        %al, %eax
  ret

llvm-svn: 130615

This folds away silly stuff like (a&255)/1000 -> 0.

llvm-svn: 130614

llvm-svn: 130613

partial ordering of function templates, use a simple superset
relationship rather than the convertibility-implying
isMoreQualifiedThan/compatibilyIncludes relationship. Fixes partial
ordering between references and address-space-qualified references.

llvm-svn: 130612

is a bit ugly, but doing it on the base MCStreamer would be redundant
with the object streamer which does it using SD.

llvm-svn: 130611

llvm-svn: 130609

SynthesizeByrefCopyDestroyHelper(). No change in functionality intended.

llvm-svn: 130608

llvm-svn: 130606

types after looking through arrays. Arrays with an unknown bound seem to
be specifically allowed in the library type traits in C++0x, and GCC's
builtin __is_trivial returns 'true' for the type 'int[]'. Now Clang
agrees with GCC about __is_trivial here.

Also hardens these methods against dependent types by just returning false.

llvm-svn: 130605

trait arguments. Reflow the logic to use early exit instead of a complex
condition expression. Switch to a switch for acting on different type
traits and add a bunch of the recently implemented type traits here.
This fixes one of the regressions with the new __is_standard_layout
trait to again require a complete type. It also fixes some latent bugs
in other traits that never did impose this despite the standard
requiring it. However, all these bugs were hidden for non-borland
systems where the default is to require a complete type.

It's unclear to me what the best approach here is: providing an explicit
lists for the ones requiring complete types only w/ Borland and using
a default for the rest, or forcing this switch to enumerate the traits
and make it clear which way each one goes.

I'm still working on cleaning up the tests so that they actually catch
this, a much more comprehensive update to the tests will come once I've
worked through the bugs I'm finding via inspection.

llvm-svn: 130604

based on Doug's preferences when we discussed this in IRC. This brings
the wording more in line with the standard.

llvm-svn: 130603

a Type method isStandardLayoutType, to keep our user API matching the
type trait builtins as closely as possible. Also, implement it in terms
of other Type APIs rather than in terms of other type traits. This
models the implementation on that of isLiteralType and isTrivialType.
There remain some common problems with these traits still, so this is
a bit of a WIP. However, we can now fix all of these traits at the same
time and in a consistent manner.

llvm-svn: 130602

type trait. The previous implementation suffered from several problems:

1) It implemented all of the logic in RecordType by walking over every
   base and field in a CXXRecordDecl and validating the constraints of
   the standard. This made for very straightforward code, but is
   extremely inefficient. It also is conceptually wrong, the logic tied
   to the C++ definition of standard-layout classes should be in
   CXXRecordDecl, not RecordType.
2) To address the performance problems with #1, a cache bit was added to
   CXXRecordDecl, and at the completion of every C++ class, the
   RecordType was queried to determine if it was a standard layout
   class, and that state was cached. Two things went very very wrong
   with this. First, the caching version of the query *was never
   called*. Even within the recursive steps of the walk over all fields
   and bases the caching variant was not called, making each query
   a full *recursive* walk. Second, despite the cache not being used, it
   was computed for every class declared, even when the trait was never
   used in the program. This probably significantly regressed compile
   time performance for edge-case files.
3) An ASTContext was required merely to query the type trait because
   querying it performed the actual computations.
4) The caching bit wasn't managed correctly (uninitialized).

The new implementation follows the system for all the other traits on
C++ classes by encoding all the state needed in the definition data and
building up the trait incrementally as each base and member are added to
the definition of the class.

The idiosyncracies of the specification of standard-layout classes
requires more state than I would like; currently 5 bits. I could
eliminate one of the bits easily at the expense of both clarity and
resilience of the code. I might be able to eliminate one of the other
bits by computing its state in terms of other state bits in the
definition. I've already done that in one place where there was a fairly
simple way to achieve it.

It's possible some of the bits could be moved out of the definition data
and into some other structure which isn't serialized if the serialized
bloat is a problem. That would preclude serialization of a partial class
declaration, but that's likely already precluded.

Comments on any of these issues welcome.

llvm-svn: 130601

llvm-svn: 130600

llvm-svn: 130599

llvm-svn: 130598