llvm-svn: 177015

Fix a bug in the calculation of the VEX.B bit for FMA4 rr with the VEX.W bit set. The VEX.B was being calculated from the wrong operand. Fixes at least some portion of PR14185.

llvm-svn: 177014

llvm-svn: 177013

llvm-svn: 177012

Teach X86 MC instruction lowering that VMOVAPSrr and other VEX-encoded register to register moves should be switched from using the MRMSrcReg form to the MRMDestReg form if the source register is a 64-bit extended register and the destination register is not. This allows the instruction to be encoded using the 2-byte VEX form instead of the 3-byte VEX form. The GNU assembler has similar behavior.

llvm-svn: 177011

- Fix the typo on type checking

llvm-svn: 177010

llvm-svn: 177009

something else and forgot to remove.

llvm-svn: 177007

llvm-svn: 177006

llvm-svn: 177005

llvm-svn: 177004

template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.

This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.

This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.

The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template.  That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.

rdar://12350696

llvm-svn: 177003

constructs default arguments. It can now take default arguments from
cl::opt'ions. Add a new -default-gcov-version=... option, and actually test it!

Sink the reverse-order of the version into GCOVProfiling, hiding it from our
users.

llvm-svn: 177002

llvm-svn: 177001

[modules] Check for delegating constructor cycles when building a module and don't write them out to the module file.

llvm-svn: 177000

Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.

That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.

We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.

This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.

llvm-svn: 176999

llvm-svn: 176998

llvm-svn: 176997

llvm-svn: 176996

Clients of MemoryBuffer::getOpenFile expect it not to take ownership of the file
descriptor passed in. So don't.

llvm-svn: 176995

emitProfileNotes(), similar to emitProfileArcs(). Also update its comment.

Also add a comment on Version[4] (there will be another comment in clang later),
and compress lines that exceeded 80 columns.

llvm-svn: 176994

llvm-svn: 176993

Don't get dirty page size if we are not going to send it back

llvm-svn: 176992

llvm-svn: 176991

(extra cleanup/fallout from r176983 - not sure why I didn't catch this locally)

llvm-svn: 176988

llvm-svn: 176987

This doesn't reset all of the target options within the TargetOptions
object. This is because some of those are ABI-specific and must be determined if
it's okay to change those on the fly.

llvm-svn: 176986

The back-end cannot differentiate between functions that are from a .ll file and
those generated from the front-end. We cannot then take the non-precense of
these attributes as a "false" value. Have the front-end explicitly set the value
to 'true' or 'false' depending upon what is actually set.

llvm-svn: 176985

llvm-svn: 176984

llvm-svn: 176983

llvm-svn: 176980

llvm-svn: 176978

codegen passes. This brings it in to line with clang and llc's codegen setup,
and tidies up the code.

If I understand correctly, adding ModulePasses to a FunctionPassManager is
bogus. It only seems to explode if an added ModulePass depends on a
FunctionPass though, which might be why this code has survived so long.

Fixes <rdar://problem/13386816>.

llvm-svn: 176977

In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.

Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.

Part of rdar://13391765

llvm-svn: 176976

This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.

Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.

llvm-svn: 176975

llvm-svn: 176974

Summary: No functionality change.

Reviewers: Bigcheese

Reviewed By: Bigcheese

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D535

llvm-svn: 176973

- fix TestCPPBool (was failing with some versions of GCC due to num_breakpoint_locations)
- speed up tests by skipping git/svn revision parsing by the test harness when running in lit-compatible (parsable) mode

This should resolve the failures reported by http://lab.llvm.org:8011/builders/lldb-x86_64-linux

llvm-svn: 176972

in the LLVM assembly language output.

llvm-svn: 176971

llvm-svn: 176970