llvm-svn: 190914

argument list, but could be instantiated with argument list of <>.

llvm-svn: 190913

PR17142.

llvm-svn: 190912

llvm-svn: 190911

referenced, try to instantiate its definition in order to complete the type.

llvm-svn: 190910

as suggested by Jordan on IRC. Also, use the unqualified name
in Job.cpp.

And while we're here, refer to StringRef with the unqualified
name, because we have a using directive for that too.

llvm-svn: 190909

This will define _MSC_VER to 1700 by default and avoid linker errors
from /failifmismatch linker directives in the C++ standard headers.

Most people trying out the Visual Studio integration are using 2012,
since that's the only version that clang-format works with.  This way
they don't have to pass funky -Xclang -fmsc-version=1700 flags just to
link against the standard C++ runtime.

llvm-svn: 190908

The first one broke the build, and the latter one made it worse.

llvm-svn: 190907

Seems like it was intentional to export ArgStringList as
driver::ArgStringList, and e.g. examples/clang-interpreter/main.cpp
uses it this way.

However, exporting it with a typedef seems like a more common way to do it.

llvm-svn: 190906

llvm-svn: 190905

This reverts commit r190895 which reverted r190892.

llvm-svn: 190904

llvm-svn: 190903

I don't think it belongs in the header, but seems handy in the .cpp file.

llvm-svn: 190902

presense of parenthesized enumerator initializers.

llvm-svn: 190901

The /GS- flag is used to turn off run-time buffer security checks (/GS).
Since no such checks are enabled in the first place, I think we should just
ignore this flag.

llvm-svn: 190900

If address space 0 was smaller than the address space
in a constant inttoptr/ptrtoint pair, the wrong mask size
would be used.

llvm-svn: 190899

Summary:
We indicate that the object files are safe by emitting a @feat.00
absolute address symbol.  The address is presumably interpreted as a
bitfield of features that the compiler would like to enable.  Bit 0 is
documented in the PE COFF spec to opt in to "registered SEH", which is
what /safeseh enables.

LLVM's object files are safe by default because LLVM doesn't know how to
produce SEH handlers.

Reviewers: Bigcheese

CC: llvm-commits

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

llvm-svn: 190898

llvm-svn: 190897

For now it happens the argument is always the same.

llvm-svn: 190896

This reverts commit r190892.

llvm-svn: 190895

'deprected' setters either. // rdar://14989365

llvm-svn: 190894

llvm-svn: 190893

Summary:
When selecting a mangling for an anonymous tag type:
- We should first try it's typedef'd name.
- If that doesn't work, we should mangle in the name of the declarator
  that specified it as a declaration specifier.
- If that doesn't work, fall back to a static mangling of
  <unnamed-type>.

This should make our anonymous type mangling compatible.

This partially fixes PR16994; we would need to have an implementation of
scope numbering to get it right (a separate issue).

Reviewers: rnk, rsmith, rjmccall, cdavis5x

CC: cfe-commits

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

llvm-svn: 190892

To avoid regressions with bitfield optimizations, this slicing should take place
later, like ISel time.

llvm-svn: 190891

entities. // rdar://14989365

llvm-svn: 190890

- prompt disappears with older libedit versions
- will re-enable once we have a recent libedit on the buildbot in question

llvm-svn: 190889

In particular, this means we emit non-external symbols defined to
variables, such as aliases or absolute addresses.

This is needed to implement /safeseh, and it appears there was some
confusion about what symbols to emit previously.

llvm-svn: 190888

llvm-svn: 190887

llvm-svn: 190886

Some of this code is no longer necessary since int<->ptr casts are no
longer occur as of r187444.

This also fixes handling vectors of pointers, and adds a bunch of new
testcases for vectors and address spaces.

llvm-svn: 190885

llvm-svn: 190884

Documenting a design choice to generate only medium model sequences for TLS
addresses at this time.  Small and large code models could be supported if
necessary.

llvm-svn: 190883

Large code model on PPC64 requires creating and referencing TOC entries when
using the addis/ld form of addressing.  This was not being done in all cases.
The changes in this patch to PPCAsmPrinter::EmitInstruction() fix this.  Two
test cases are also modified to reflect this requirement.

Fast-isel was not creating correct code for loading floating-point constants
using large code model.  This also requires the addis/ld form of addressing.
Previously we were using the addis/lfd shortcut which is only applicable to
medium code model.  One test case is modified to reflect this requirement.

llvm-svn: 190882

of retainable object (readonly or otherwise).

llvm-svn: 190881

rdar://14461559

llvm-svn: 190880

that was introduced by r190873.

llvm-svn: 190879

declared as getter with or without setter method.
// rdar://15010020

llvm-svn: 190878

constants before using them in the IR interpreter.

Patch by Félix Cloutier.

llvm-svn: 190877

Upcoming SLP vectorization improvements will want to be able to estimate costs
of horizontal reductions. Add infrastructure to support this.

We model reductions as a series of (shufflevector,add) tuples ultimately
followed by an extractelement. For example, for an add-reduction of <4 x float>
we could generate the following sequence:

 (v0, v1, v2, v3)
   \   \  /  /
     \  \  /
       +  +

 (v0+v2, v1+v3, undef, undef)
    \      /
 ((v0+v2) + (v1+v3), undef, undef)

 %rdx.shuf = shufflevector <4 x float> %rdx, <4 x float> undef,
                           <4 x i32> <i32 2, i32 3, i32 undef, i32 undef>
 %bin.rdx = fadd <4 x float> %rdx, %rdx.shuf
 %rdx.shuf7 = shufflevector <4 x float> %bin.rdx, <4 x float> undef,
                          <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
 %bin.rdx8 = fadd <4 x float> %bin.rdx, %rdx.shuf7
 %r = extractelement <4 x float> %bin.rdx8, i32 0

This commit adds a cost model interface "getReductionCost(Opcode, Ty, Pairwise)"
that will allow clients to ask for the cost of such a reduction (as backends
might generate more efficient code than the cost of the individual instructions
summed up). This interface is excercised by the CostModel analysis pass which
looks for reduction patterns like the one above - starting at extractelements -
and if it sees a matching sequence will call the cost model interface.

We will also support a second form of pairwise reduction that is well supported
on common architectures (haddps, vpadd, faddp).

 (v0, v1, v2, v3)
  \   /    \  /
 (v0+v1, v2+v3, undef, undef)
    \     /
 ((v0+v1)+(v2+v3), undef, undef, undef)

  %rdx.shuf.0.0 = shufflevector <4 x float> %rdx, <4 x float> undef,
        <4 x i32> <i32 0, i32 2 , i32 undef, i32 undef>
  %rdx.shuf.0.1 = shufflevector <4 x float> %rdx, <4 x float> undef,
        <4 x i32> <i32 1, i32 3, i32 undef, i32 undef>
  %bin.rdx.0 = fadd <4 x float> %rdx.shuf.0.0, %rdx.shuf.0.1
  %rdx.shuf.1.0 = shufflevector <4 x float> %bin.rdx.0, <4 x float> undef,
        <4 x i32> <i32 0, i32 undef, i32 undef, i32 undef>
  %rdx.shuf.1.1 = shufflevector <4 x float> %bin.rdx.0, <4 x float> undef,
        <4 x i32> <i32 1, i32 undef, i32 undef, i32 undef>
  %bin.rdx.1 = fadd <4 x float> %rdx.shuf.1.0, %rdx.shuf.1.1
  %r = extractelement <4 x float> %bin.rdx.1, i32 0

llvm-svn: 190876

llvm-svn: 190875