When using AA to break false chain dependencies, we need to track multiple
stores per object in ScheduleDAGInstrs. Historically, we tracked potential alias
chains at the object level, and so all loads of an object would retain
dependencies on any store to that object. With AA, however, this is not
sufficient: non-overlapping stores and loads to the same object all need to be
tested for dependencies separately, we cannot only test all loads to an object
against only the last store (see PR18497 for an explicit example).

To mitigate any unwelcome compile-time impact when not using AA, only one store
is kept in the list per object when not using AA.

This, along with a stack coloring change to come shortly, will provide a test
case, fix PR18497 (and allow LLVM to compile itself using -enable-aa-sched-mi
on x86-64).

llvm-svn: 199657

In optimized hybrid execution we do not use DynamoRIO private loader, which
mangles TLS access, so we can access the application's TLS directly.

Patch by Qin Zhao.

llvm-svn: 199655

The addition of IC_OPSIZE_ADSIZE in r198759 wasn't quite complete. It
also turns out to have been unnecessary. The disassembler handles the
AdSize prefix for itself, and doesn't care about the difference between
(e.g.) MOV8ao8 and MOB8ao8_16 definitions. So just let them coexist and
don't worry about it.

llvm-svn: 199654

llvm-svn: 199653

The disassembler has a special case for 'L' vs. 'W' in its heuristic for
checking for 32-bit and 16-bit equivalents. We could expand the heuristic,
but better just to be consistent in using the 'L' suffix.

llvm-svn: 199652

Not quite sure why this was marked isAsmParserOnly, but it means that the
disassembler can't see it either.

llvm-svn: 199651

When disassembling in 16-bit mode the meaning of the OpSize bit is
inverted. Instructions found in the IC_OPSIZE context will actually
*not* have the 0x66 prefix, and instructions in the IC context will
have the 0x66 prefix. Make use of the existing special-case handling
for the 0x66 prefix being in the wrong place, to cope with this.

llvm-svn: 199650

Aside from cleaning up the code, this also adds support for the -code16
environment and actually enables the MODE_16BIT mode that was previously
not accessible.

There is no point adding any testing for 16-bit yet though; basically
nothing will work because we aren't handling the OpSize prefix correctly
for 16-bit mode.

llvm-svn: 199649

llvm-svn: 199648

various opt verifier commandline options.

Mostly mechanical wiring of the verifier to the new pass manager.
Exercises one of the more unusual aspects of it -- a pass can be either
a module or function pass interchangably. If this is ever problematic,
we can make things more constrained, but for things like the verifier
where there is an "obvious" applicability at both levels, it seems
convenient.

This is the next-to-last piece of basic functionality left to make the
opt commandline driving of the new pass manager minimally functional for
testing and further development. There is still a lot to be done there
(notably the factoring into .def files to kill the current boilerplate
code) but it is relatively uninteresting. The only interesting bit left
for minimal functionality is supporting the registration of analyses.
I'm planning on doing that on top of the .def file switch mostly because
the boilerplate for the analyses would be significantly worse.

llvm-svn: 199646

Add support for the symbol(tlsldo) relocation. This is required in order to 
solve PR18554.

Reviewed by R. Golin, A. Korobeynikov.

llvm-svn: 199644

llvm-svn: 199642

llvm-svn: 199640

ADDITIONAL_HEADERS is intended to add header files for IDEs as hint.

For example:
  add_llvm_library(LLVMSupport
    Host.cpp
    ADDITIONAL_HEADERS
      Unix/Host.inc
      Windows/Host.inc
    )

llvm-svn: 199639

[ARM] Do not generate Tag_DIV_use=AllowDIVExt when hardware div is non-optional: it should have the default value of AllowDIVIfExists

llvm-svn: 199638

coding standards, and instead fix the existing section.

Thanks to Daniel Jasper for pointing out we already had a section
devoted to this topic. Instead of adding sections, just hack on this
section some. Also fix the example in the anonymous namespace section
below it to agree with the new advice.

As a re-cap, this switches the LLVM preferred style to never indent
namespaces. Having two approaches just led to endless (and utterly
pointless) debates about what was "small enough". This wasn't helping
anyone. The no-indent rule is easy to understand and doesn't really make
anything harder to read. Moreover, with tools like clang-format it is
considerably nicer to have simple consistent rules.

llvm-svn: 199637

llvm-svn: 199633

Now instead of just looking in the system root for it, we also look
relative to the clang binary's directory. This should "just work" in
almost all cases. I've added test cases accordingly.

This is probably *very* worthwhile to backport to the 3.4 branch so that
folks can check it out, build it, and use that as their host compiler
going forward.

llvm-svn: 199632

This test fails the newly added regression tests.

llvm-svn: 199631

type units were enabled. The crux of the issue is that the
addDwarfTypeUnitType routine can end up being indirectly recursive. In
this case, the reference into the dense map (TU) became invalid by the
time we popped all the way back and used it to add the DIE type
signature.

Instead, use early return in the case where we can bypass the recursive
step and creating a type unit. Then use the pointer to the new type unit
to set up the DIE type signature in the case where we have to.

I tried really hard to reduce a testcase for this, but it's really
annoying. You have to get this to be mid-recursion when the densemap
grows. Even if we got a test case for this today, it'd be very unlikely
to continue exercising this pattern.

llvm-svn: 199630

Fix all the remaining lost-fast-math-flags bugs I've been able to find.  The most important of these are cases in the generic logic for combining BinaryOperators.
This logic hadn't been updated to handle FastMathFlags, and it took me a while to detect it because it doesn't show up in a simple search for CreateFAdd.

llvm-svn: 199629

llvm-svn: 199628

llvm-svn: 199627

This attribute is supported by GCC.  More generally it should
probably be a type attribute, but this behavior matches 'nonnull'.

This patch does not include warning logic for checking if a null
value is returned from a function annotated with this attribute.
That will come in subsequent patches.

llvm-svn: 199626

llvm-svn: 199625

Remove hard tabs in favour of spaces.  NFC.

llvm-svn: 199624

The alias test "exprf x 1234" expands to "expr -f x 1234" and is
expected to fail: it ends up trying to evaluate the invalid expression

    void
    $__lldb_expr(void *$__lldb_arg)
    {
        -f x 1234;
    }

On FreeBSD LLDB ends up finding a static function f() in a math library,
and thus the error produced does not include "use of undeclared
identifier 'f'".

We will report failure to parse the expression in any case, so require
only that error message.

llvm-svn: 199623

Have I mentioned that functions returning true on error and false on
success are confusing? They're more confusing when their name is
"verify". Anyways...

llvm-svn: 199622

For FCMEQ, FCMGE, FCMGT, FCMLE and FCMLT, floating point zero will be
printed as #0.0 instead of #0. To support the history codes using #0,
we consider to let asm parser accept both #0.0 and #0.

llvm-svn: 199621

(and to mention namespace ending comments). This is based on a quick
discussion on the developer mailing list where there was essentially no
objections to a simple and consistent rule. This should avoid future
debates about whether or not a namespace is "big enough" to indent. It
also matches clang-format's current behavior with LLVM source code which
hasn't really seen any opposition in code reviews that I spot checked.

llvm-svn: 199620

Implement type trait primitives used in the latest edition of the Microsoft
standard C++ library type_traits header.

With this change we can parse much of the Visual Studio 2013 standard headers,
particularly anything that includes <type_traits>.

Fully implemented, available in all language modes:

 * __is_constructible()
 * __is_nothrow_constructible()
 * __is_nothrow_assignable()

Partially implemented, semantic analysis WIP, available as MS extensions:

 * __is_destructible()
 * __is_nothrow_destructible()

llvm-svn: 199619

Check all default ctors, not just the first one we see. This brings
__has_nothrow_constructor() in line with the other unary type traits.

A C++ class can have multiple default constructors but clang was only checking
the first one written, presumably due to ambiguity in the GNU specification.

MSVC has the same bug, while g++ has the correct implementation which we now
match.

llvm-svn: 199618

such an assert will fail in invalid code that does so!

llvm-svn: 199617

Move the retrieval of VT after all of the early exits from PerformOrCombine that do not use VT. NFC.

llvm-svn: 199612

[APInt] Fix nearestLogBase2 to return correct answers for very large APInt and APInt with a bitwidth of 1.

I also improved the comments, added some more tests, etc.

llvm-svn: 199610

This was due to arithmetic overflow in the getNumBits() computation. Now we
cast BitWidth to a uint64_t so that does not occur during the computation. After
the computation is complete, the uint64_t is truncated when the function
returns.

I know that this is not something that is likely to happen, but it *IS* a valid
input and we should not blow up.

llvm-svn: 199609

Also make them vector-aware.

llvm-svn: 199608

llvm-svn: 199605

llvm-svn: 199604

llvm-svn: 199602