Adds LLVM_PROFDATA_FILE option to allow specifying a profile data file to be used during compilation of LLVM and subprojects.

llvm-svn: 250108

Fix the buildbot; this test also requires ppc target support.

llvm-svn: 250107

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

llvm-svn: 250106

llvm-svn: 250105

Now that the target relocation handle will see R_PPC64_TOC, fix the test case
accordingly.

llvm-svn: 250104

This is essentially pattern-matching against the x86 target, and generates the
analogous PPC64 relocation.

llvm-svn: 250102

This is mostly an adaptation of the code in LLVM's
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp, and handles a sufficient
number of relocations to link a 'hello world' program on big-Endian PPC64/Linux
(ELF v1 ABI).

llvm-svn: 250101

PPC64 has several special sections that are intended to be accessed from the
TOC base pointer. When a .got is present, the TOC base pointer is .got + 0x8000
(as specified by the ABI). Furthermore, the glibc startup code contains an
assumption that a 16-bit relocation can hold the offset from the TOC base value
to the beginning of the .toc section. Thus, we need to make sure that .toc
appears after .got. This much, at least, is required in practice. The other
PPC64 special sections (.toc, .toc1, .opd, etc.) should also be close by to
optimize access by smaller TOC-base-pointer offsets.

llvm-svn: 250100

We already silently ignore the /RTC, which controls the same functionality.

llvm-svn: 250099

Summary:
This check flags all usages of static_cast, where a base class is casted
to a derived class.
In those cases, a fixit is provided to convert the cast to a
dynamic_cast.

Use of these casts can violate type safety and cause the program to
access a variable that is actually of type X to be accessed as if it
were of an unrelated type Z.

This rule is part of the "Type safety" profile of the C++ Core
Guidelines, see
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#-type2-dont-use-static_cast-downcasts-use-dynamic_cast-instead

Depends on D13313

Reviewers: alexfh, sbenza, bkramer, aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 250098

Fix Bug 25103 - _cxa_demangle improperly demangles virtual thunks. Thanks to Jason King for the report and suggested fix

llvm-svn: 250097

llvm-svn: 250096

And remove git getLocalSymVA because there's no user of the function anymore.

llvm-svn: 250095

Add support for the `-fdebug-prefix-map=` option as in GCC.  The syntax is
`-fdebug-prefix-map=OLD=NEW`.  When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW.  This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).

Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.

Addresses PR24619.

llvm-svn: 250094

This change commits: http://reviews.llvm.org/D13625

llvm-svn: 250093

This will allow us to optimize C++ template code with Polly. This support is
mostly for debugging purpose and individual experiments. The ultimate goal is
still to run Polly later in the pass manager when inlining already happened.

llvm-svn: 250092

instead of llvm::PassManagerBuilder::EP_EarlyAsPossible. This will allow us
to run actual module passes in Polly's canonicalization sequence, but should
otherwise have only little impact.

llvm-svn: 250091

This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:

  int foo(int a) __attribute__((enable_if(a > 0, "")));
  int (*p)(int) = &foo;
  int result = p(-1); // compilation succeeds; calls foo(-1)

Overloading logic has been updated to reflect this change, as well.

Functions with enable_if attributes that are always true are still
allowed to have their address taken.

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

llvm-svn: 250090

In JumpThreading pass, the branch weight metadata is not updated after CFG modification. Consider the jump threading on PredBB, BB, and SuccBB. After jump threading, the weight on BB->SuccBB should be adjusted as some of it is contributed by the edge PredBB->BB, which doesn't exist anymore. This patch tries to update the edge weight in metadata on BB->SuccBB by scaling it by 1 - Freq(PredBB->BB) / Freq(BB->SuccBB). 

Differential revision: http://reviews.llvm.org/D10979

llvm-svn: 250089

We made them SP relative back in March (r233137) because that's the
value the runtime passes to EH functions. With the new cleanuppad IR,
funclets adjust their frame argument from SP to FP, so our offsets
should now be FP-relative.

llvm-svn: 250088

Rafael requested some additional commentary (post-commit review of r249760), to
make it clear this is intended and necessary.

llvm-svn: 250087

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

llvm-svn: 250086

Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong
assumption that for non-AVX512 targets, the source type and destination type
of a type-legalized setcc node were always the same type.

This assumption was unfortunately incorrect; the type legalizer is not always
able to promote the return type of a setcc to the same type as the first
operand of a setcc.

In the case of a vsetcc node, the legalizer firstly checks if the first input
operand has a legal type. If so, then it promotes the return type of the vsetcc
to that same type. Otherwise, the return type is promoted to the 'next legal
type', which, for vectors of MVT::i1 is always a 128-bit integer vector type.

Example (-mattr=+avx):

  %0 = trunc <8 x i32> %a to <8 x i23>
  %1 = icmp eq <8 x i23> %0, zeroinitializer

The initial selection dag for the code above is:

v8i1 = setcc t5, t7, seteq:ch
  t5: v8i23 = truncate t2
    t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1
    t7: v8i32 = build_vector of all zeroes.

The type legalizer would firstly check if 't5' has a legal type. If so, then it
would reuse that same type to promote the return type of the setcc node.
Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to
promote the return type of the setcc node. Consequently, the setcc return type
is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the
following dag node:
  v8i16 = setcc t32, t25, seteq:ch

  where t32 and t25 are now values of type v8i32.

Before this patch, function LowerVSETCC would have wrongly expanded the setcc
to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an
instruction. In our case, ISel would have matched a VPCMPEQWrr:
  t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25

However, t36 and t25 are both VR256, while the result type is instead of class
VR128. This inconsistency ended up causing the insertion of COPY instructions
like this:
  %vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3

Which is an invalid full copy (not a sub register copy).
Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy
instruction" in the attempt to expand the malformed pseudo COPY instructions.

This patch fixes the problem adding the missing logic in LowerVSETCC to handle
the corner case of a setcc with 128-bit return type and 256-bit operand type.

This problem was originally reported by Dimitry as PR25080. It has been latent
for a very long time. I have added the minimal reproducible from that bugzilla
as test setcc-lowering.ll.

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

llvm-svn: 250085

set to true, but all plans run by RunThreadPlan need to have this set to false so they will
return control to RunThreadPlan without consulting plans higher on the stack.

Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior.

<rdar://problem/22543166>

llvm-svn: 250084

strictly necessary because RunToAddress is always used as a subsidiary plan, so
it's ShouldStop seldom matters.  But get it right anyway.

llvm-svn: 250083

llvm-svn: 250082

llvm-svn: 250081

llvm-svn: 250080

llvm-svn: 250079

Fixed a bug where we'd emit multiple diagnostics if there was a problem
taking the address of an overloaded template function.

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

llvm-svn: 250078

llvm-svn: 250077

llvm-svn: 250076

llvm-svn: 250075

Turn const/const& into value type for BlockFrequency in functions of this class. Also fix a naming issue. NFC.

llvm-svn: 250074

llvm-svn: 250073

llvm-svn: 250072

llvm-svn: 250071

No tests fail with this enabled so I assume it was an accident
that it isn't enabled now.

llvm-svn: 250070

llvm-svn: 250069

This was a minor bug in r249492. Calling PrepareEHLandingPad on a
non-landingpad was a no-op, but it attempted to get the generic pointer
register class, which apparently doesn't exist for some targets.

llvm-svn: 250068