When __declspec(align()) is applied to a bitfield it affects the 
alignment rather than the required alignment of the struct.  The major 
feature that this patch adds is that the alignment of the structure 
obeys the alignment of __declspec(align()) from the bitfield over the 
value specified in pragma pack.

Test cases are included.
The patch also includes some small cleanups in recordlayoutbuilder and 
some cleanups to some lit tests, including line endings (but no 
functionality change to lit tests)

llvm-svn: 205994

Move the iterators into the range the same way the range's ctor moves
them into the members.

Also remove some redundant top level parens in the return statement.

llvm-svn: 205993

llvm-svn: 205992

llvm-svn: 205991

To support compressing the debug_line section that contains multiple
fragments (due, I believe, to variation in choices of line table
encoding depending on the size of instruction ranges in the actual
program code) we needed to support compressing multiple MCFragments in a
single pass.

This patch implements that behavior by mutating the post-relaxed and
relocated section to be the compressed form of its former self,
including renaming the section.

This is a more flexible (and less invasive, to a degree) implementation
that will allow for other features such as "use compression only if it's
smaller than the uncompressed data".

Compressing debug_frame would be a possible further extension to this
work, but I've left it for now. The hurdle there is alignment sections -
which might require going as far as to refactor
MCAssembler.cpp:writeFragment to handle writing to a byte buffer or an
MCObjectWriter (there's already a virtual call there, so it shouldn't
add substantial compile-time cost) which could in turn involve
refactoring MCAsmBackend::writeNopData to use that same abstraction...
which involves touching all the backends. This would remove the limited
handling of fragment writing seen in
ELFObjectWriter.cpp:getUncompressedData which would be nice - but it's
more invasive.

I did discover that I (perhaps obviously) don't need to handle
relocations when I rewrite the fragments - since the relocations have
already been applied and computed (and stored into
ELFObjectWriter::Relocations) by this stage (necessarily, because we
need to have written any immediate values or assembly-time relocations
into the data already before we compress it, which we have). The test
case doesn't necessarily cover that in detail - I can add more test
coverage if that's preferred.

llvm-svn: 205990

To support compression for debug_line and debug_frame a different
approach is required. To simplify review, revert the old implementation
and XFAIL the test case. New implementation to follow shortly.

Reverts r205059 and r204958.

llvm-svn: 205989

llvm-svn: 205988

Convenience wrapper to make dealing with sub-ranges easier. Like the
iterator_range<> itself, if/when this sort of thing gets standards
blessing, it will be replaced by the official version.

llvm-svn: 205987

alignments on vld/vst instructions.  And report errors for
alignments that are not supported.

While this is a large diff and an big test case, the changes
are very straight forward.  But pretty much had to touch
all vld/vst instructions changing the addrmode to one of the
new ones that where added will do the proper checking for
the specific instruction.

FYI, re-committing this with a tweak so MemoryOp's default
constructor is trivial and will work with MSVC 2012. Thanks
to Reid Kleckner and Jim Grosbach for help with the tweak.

rdar://11312406

llvm-svn: 205986

llvm-svn: 205985

llvm-svn: 205984

We only care about cmake and the buildbots test that it works.

llvm-svn: 205983

llvm-svn: 205982

This ensures that the overall struct size will be a multiple of 4, as
required by the ABI.

llvm-svn: 205981

llvm-svn: 205980

This reverts commit r205974, it turns out that this wasn't such a great idea
after all. Using DIVariable as return value is self-documenting and marginally
more type safe.

llvm-svn: 205979

The "unexpected value" message only matters to me, but is bound to make the experience more confusing for people when some uninitialized memory looks like an NSNumber and then can't be formatted properly, and that error comes out in the UI

Just drop the error message entirely - nobody but me cares

llvm-svn: 205978

Emitting the PGO initialization in EmitGlobalFunctionDefinition is
inefficient, since this only has an effect once per module.  We move
this to Release() with the rest of the once-per-module logic.

llvm-svn: 205977

Some minor improvements to the thread safety intermediate language -- mostly const correctness and reformatting. Fixes the types involved with castOpcode().

llvm-svn: 205976

With the VFS, it is easy to hit modified umbrellas by overriding the
umbrella header, and what we want is to rebuild, not to fail.

llvm-svn: 205975

llvm-svn: 205974

into a function.

llvm-svn: 205973

No functionality change.

llvm-svn: 205972

llvm-svn: 205971

  - LLVMSupport.dll
  - libLLVMSupport.dll.a

llvm-svn: 205969

Summary:
Similarly, the HasMips64 on the 64-bit move InstAlias is a test for 64-bit
GPR's.

No functional change.

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://reviews.llvm.org/D3263

llvm-svn: 205968

llvm-svn: 205967

llvm-svn: 205966

This commit reapplies 205018. After 205855 we should correctly vectorize
intrinsics.

llvm-svn: 205965

Summary:
It is now the smallest superset for these ISA's.

FeatureMips4 now contains FeatureFPIdx since [ls][dw]xc1 were added in MIPS-IV.
Made the FPIdx feature bit lowercase so that it can be used in the -mattr option.

Depends on D3274

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://reviews.llvm.org/D3275

llvm-svn: 205964

llvm-svn: 205963

llvm-svn: 205962

llvm-svn: 205961

Whitespace only.  No functional change intended.

llvm-svn: 205960

llvm-svn: 205959

llvm-svn: 205958

llvm-svn: 205957

llvm-svn: 205956

Introduce ScalarTraits::mustQuote which determines whether or not a
StringRef needs quoting before it is acceptable to output.

llvm-svn: 205955

llvm-svn: 205954