Properly constrain the operand register class for instructions used
in [sz]ext expansion. Update more tests to use the verifier now that
we're getting the register classes correct.

rdar://12594152

llvm-svn: 188594

Teach the generic instruction selection helper functions to constrain
the register classes of their input operands. For non-physical register
references, the generic code needs to be careful not to mess that up
when replacing references to result registers. As the comment indicates
for MachineRegisterInfo::replaceRegWith(), it's important to call
constrainRegClass() first.

rdar://12594152

llvm-svn: 188593

Lots of machine verifier errors result from using a plain GPR regclass
for incoming argument copies. A more restrictive rGPR class is more
appropriate since it more accurately represents what's happening, plus
it lines up better with isel later on so the verifier is happier.
Reduces the number of ARM fast-isel tests not running with the verifier
enabled by over half.

rdar://12594152

llvm-svn: 188592

for future work. No change otherwise.

llvm-svn: 188591

 - If anyone is interested in lit's feature set, I'd appreciate any comments on
   the elaborated items.

llvm-svn: 188590

llvm-svn: 188589

Before this patch we would warn and drop the attribute in
extern const char test3[] __attribute__((used)) = "";

llvm-svn: 188588

llvm-svn: 188587

This regards how mips16 is viewed. It's not really a target type but
there has always been a target for it in the td files. It's more properly
-mcpu=mips32 -mattr=+mips16 . This is how clang treats it but we have
always had the -mcpu=mips16 which I probably should delete now but it will
require updating all the .ll test cases for mips16. In this case it changed
how we decide if we have a count bits instruction and whether instruction
lowering should then expand ctlz. Now that we have dual mode compilation,
-mattr=+mips16 really just indicates the inital processor mode that
we are compiling for. (It is also possible to have -mcpu=64 -mattr=+mips16
but as far as I know, nobody has even built such a processor, though there
is an architecture manual for this).

llvm-svn: 188586

DebugInfo: Canonicalize namespaces to avoid emitting multiple namespaces with the same name but different lines

Updated test case to not rely on line numbers in more cases (it's hard
to use the @ check syntax for debug info test cases (due to the
interesting ordering of metadata) and this case in particular (given the
hash-line directive)) - left a few in there to cover the line number
information for these.

llvm-svn: 188585

Clang doesn't support the MSVC __cpuid intrinsic yet, and fixing that is
blocked on some fairly complicated issues.

llvm-svn: 188584

llvm-svn: 188583

llvm-svn: 188582

llvm-svn: 188581

Replace some DenseMap keys with simpler structures that don't need another DenseMapInfo specialization.

llvm-svn: 188580

llvm-svn: 188579

llvm-svn: 188578

DebugInfo: Allow the addition of other (such as static data) members to a record type after construction

Plus a type cleanup & minor fix to enumerate members of declarations.

llvm-svn: 188577

This reduces Clang's .dwo (fission debug info) size by 23% over
Clang+LLVM.

llvm-svn: 188576

This is the correct type (as is demonstrated by the fact that the caller
didn't need to change) & will be useful in a future patch.

llvm-svn: 188575

CF functions coming from static analyzer API.

llvm-svn: 188574

safe on PPC32 SVR4 ABI

[Patch and following text by Mark Minich; committing on his behalf.]

There are FIXME's in PowerPC/PPCFrameLowering.cpp, method
PPCFrameLowering::emitPrologue() related to "negative offsets of R1"
on PPC32 SVR4. They're true, but the real issue is that on PPC32 SVR4
(and any ABI without a Red Zone), no spills may be made until after
the stackframe is claimed, which also includes the LR spill which is
at a positive offset. The same problem exists in emitEpilogue(),
though there's no FIXME for it. I intend to fix this issue, making
LLVM-compiled code finally safe for use on SVR4/EABI/e500 32-bit
platforms (including in particular, OS-free embedded systems & kernel
code, where interrupts may share the same stack as user code).

In preparation for making these changes, to make the diffs for the
functional changes less cluttered, I am providing the non-functional
refactorings in two stages:

Stage 1 does some minor fluffy refactorings to pull multiple method
calls up into a single bool, creating named bools for repeated uses of
obscure logic, moving some code up earlier because either stage 2 or
my final version will require it earlier, and rewording/adding some
comments. My stage 1 changes can be characterized as primarily fluffy
cleanup, the purpose of which may be unclear until the stage 2 or
final changes are made.

My stage 2 refactorings combine the separate PPC32 & PPC64 logic,
which is currently performed by largely duplicate code, into a single
flow, with the differences handled by a group of constants initialized
early in the methods.

This submission is for my stage 1 changes. There should be no
functional changes whatsoever; this is a pure refactoring.

llvm-svn: 188573

If an ELF relocation is pointed at an absolute address, it will have a symbol ID of zero.
RuntimeDyldELF::processRelocationRef was not previously handling this case, and was instead trying to handle it as a section-relative fixup.

I think this is the right fix here, but my elf-fu is poor on some of the more exotic platforms, so I'd appreciate it if anyone with greater knowledge could verify this.

llvm-svn: 188572

llvm-svn: 188571

llvm-svn: 188570

Libclang has a lot of functionality that is inaccessible.
The purpose of clangIDE is to move most of the functionality of libclang to it so we
can expose it and have libclang be more of a thin C wrapper over clangIDE.

Start by moving the USR generation functionality into clangIDE.

llvm-svn: 188569

llvm-svn: 188568

llvm-svn: 188567

llvm-svn: 188566

llvm-svn: 188565

llvm-svn: 188564

llvm-svn: 188563

I have a patch that edits the file. Running clang-format first makes the patch
a lot easier to review.

llvm-svn: 188562

Summary:
Refactor ArgumentAdaptativeMatcher matchers to remove the template from their declaration.
This facilitates dynamic registration. Change the registry code to use the regular overload resolution mechanism for adaptative matchers.

Reviewers: klimek

CC: cfe-commits, revane

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

llvm-svn: 188560

Fixes two recent piglit regressions with radeonsi.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188559

The logic in SIInsertWaits::getHwCounts() only really made sense for SMRD
instructions, and trying to shoehorn it into handling DS_WRITE_B32 caused
it to corrupt the encoding of that by clobbering the first operand with
the second one.

Undo that damage and only apply the SMRD logic to that.

Fixes some derivates related piglit regressions with radeonsi.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 188558

llvm-svn: 188557

llvm-svn: 188556

llvm-svn: 188555

llvm-svn: 188554