Implement IEEE-754R 2008 nextUp/nextDown functions in the guise of the function APFloat::next(bool nextDown).

rdar://13852078

llvm-svn: 182945

llvm-svn: 182943

Using updated form of newFrontendActionFactory(), Transforms now automatically
measure, if requested, how long it takes to apply a MatchFinder to a source
file. Other per-transform overhead, e.g. applying replacements, is not
currently measured. This behaviour is disabled for now and soon will be
connected to a new command line arg.

llvm-svn: 182942

to detect scops in functions with no loops, use -polly-detect-scops-in-functions-without-loops

llvm-svn: 182941

llvm-svn: 182940

llvm-svn: 182939

- clarify that vectorizer.width only applies if the vectorizer decides to
  vectorize.

llvm-svn: 182938

This fixes the test on ARM. Looks like it was broken by r182877. Not
sure if this is a bug on fast isel on ARM, but this should help fix
the ARM bots.

llvm-svn: 182937

references.  What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK).  This patch implements support for the Microsoft extension, and addresses PR13737.

llvm-svn: 182936

llvm-svn: 182935

Found by -Wdocumentation.

llvm-svn: 182934

The pattern the test originally checked for doesn't occur on other -mcpu
settings. On atom it's still there though slightly differently scheduled.

llvm-svn: 182933

This fixes:
/*
*
* something long going over the column limit.
*/

llvm-svn: 182932

on the LLDB 3.3 release.

Reviewed by: Greg Clayton and Bill Wendling

llvm-svn: 182931

llvm-svn: 182930

This test was failing on some hosts when an unexpected register was used for a
variable. This just extends the regexp to allow the new x86-64 registers.

llvm-svn: 182929

Instead of having a bunch of separate MOV8r0, MOV16r0, ... pseudo-instructions,
it's better to use a single MOV32r0 (which will expand to "xorl %reg, %reg")
and obtain other sizes with EXTRACT_SUBREG and SUBREG_TO_REG. The encoding is
smaller and partial register updates can sometimes be avoided.

Until recently, this sequence was a barrier to rematerialization though. That
should now be fixed so it's an appropriate time to make the change.

llvm-svn: 182928

llvm-svn: 182927

llvm-svn: 182926

r182872 introduced a bug in how the register-coalescer's rematerialization
handled defining a physical register. It relied on the output of the
coalescer's setRegisters method to determine whether the replacement
instruction needed an implicit-def. However, this value isn't necessarily the
same as the CopyMI's actual destination register which is what the rest of the
basic-block expects us to be defining.

The commit changes the rematerializer to use the actual register attached to
CopyMI in its decision.

This will be tested soon by an X86 patch which moves everything to using
MOV32r0 instead of other sizes.

llvm-svn: 182925

ld.u1 instead of an ld.u8.

llvm-svn: 182924

This way, it has the same default as 'patch' and also the example in the
code makes more sense as it is explicitly setting -p 1.

llvm-svn: 182923

[asan] workaround for the quemu bug in proc maps (http://code.google.com/p/address-sanitizer/issues/detail?id=160)

llvm-svn: 182922

32-bit writes on amd64 zero out the high bits of the corresponding 64-bit
register. LLVM makes use of this for zero-extension, but until now relied on
custom MCLowering and other code to fixup instructions. Now we have proper
handling of sub-registers, this can be done by creating SUBREG_TO_REG
instructions at selection-time.

Should be no change in functionality.

llvm-svn: 182921

The code to distinguish between unaligned and aligned addresses was
already there, so this is mostly just a switch-on-and-test process.

llvm-svn: 182920

PR/16177

llvm-svn: 182919

llvm-svn: 182918

[sanitizer] introduce LargeMmapAllocator::GetBlockBeginFastSingleThreaded, required for LeakSanitizer to work faster. Also fix lint.

llvm-svn: 182917

llvm-svn: 182916

llvm-svn: 182915

llvm-svn: 182914

Smallest reproduction:
/*
**
*/

llvm-svn: 182913

llvm-svn: 182912

llvm-svn: 182911

llvm-svn: 182910

llvm-svn: 182909

For COFF and MachO, sections semantically have relocations that apply to them.
That is not the case on ELF.

In relocatable objects (.o), a section with relocations in ELF has offsets to
another section where the relocations should be applied.

In dynamic objects and executables, relocations don't have an offset, they have
a virtual address. The section sh_info may or may not point to another section,
but that is not actually used for resolving the relocations.

This patch exposes that in the ObjectFile API. It has the following advantages:

* Most (all?) clients can handle this more efficiently. They will normally walk
all relocations, so doing an effort to iterate in a particular order doesn't
save time.

* llvm-readobj now prints relocations in the same way the native readelf does.

* probably most important, relocations that don't point to any section are now
visible. This is the case of relocations in the rela.dyn section. See the
updated relocation-executable.test for example.

llvm-svn: 182908

Switching the tests to use size_t instead of unsigned int to hopefully appease the Linux x64 build bot (take 2, forgot this test case).

llvm-svn: 182907

Switching the tests to use size_t instead of unsigned int to hopefully appease the Linux x64 build bot.

llvm-svn: 182906

Add support to fallback on operator new when a placement operator new[] is called for which there is no valid declaration.  This fallback only happens in Microsoft compatibility mode.  This patch addresses PR13164, and improves support for the WDK.

llvm-svn: 182905