AMDGPU : Add V_SAD_U32 instruction pattern.

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

llvm-svn: 279629

[llvm-cov] Add the project summary to each source file coverage report.

This patch includes the following changes:
- Included header "Code coverage report" and include the date that the report was created.
- Included title (as specified in a command line option, (i.e llvm-cov  -project-title="Simple Test")
- In the summary, list the elf files that the source code file has contributed to.
- Used column heading for "Line No.", "Count No.", Source".

Differential Revision: https://reviews.llvm.org/D23345

llvm-svn: 279628

Fix mismatched new/free in Process:RunPrivateStateThread

NFC

llvm-svn: 279627

[InstCombine] add assert and explanatory comment for fold removed in r279568; NFC

I deleted a fold from InstCombine at:
https://reviews.llvm.org/rL279568

because it (like any InstCombine to a constant?) should always happen in InstSimplify,
however, it's not obvious what the assumptions are in the remaining code.

Add a comment and assert to make it clearer.

Differential Revision: https://reviews.llvm.org/D23819

llvm-svn: 279626

Create subranges for new intervals resulting from live interval splitting

The register allocator can split a live interval of a register into a set
of smaller intervals. After the allocation of registers is complete, the
rewriter will modify the IR to replace virtual registers with the corres-
ponding physical registers. At this stage, if a register corresponding
to a subregister of a virtual register is used, the rewriter will check
if that subregister is undefined, and if so, it will add the <undef> flag
to the machine operand. The function verifying liveness of the subregis-
ter would assume that it is undefined, unless any of the subranges of the
live interval proves otherwise.
The problem is that the live intervals created during splitting do not
have any subranges, even if the original parent interval did. This could
result in the <undef> flag placed on a register that is actually defined.

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

llvm-svn: 279625

[mips] Preparatory work for a generic scheduler

Extend instruction definitions from nearly all ISAs to include
appropriate instruction itineraries. Change MIPS16s gp prologue
generation to use real instructions instead of using a pseudo
instruction.

Reviewers: dsanders, vkalintiris

Differential Review: https://reviews.llvm.org/D23548

llvm-svn: 279623

[X86][AVX2] Ensure on 32-bit targets that we broadcast f64 types not i64 (PR29101)

llvm-svn: 279622

[X86][F16C] Regenerated f16c tests

llvm-svn: 279621

[Loop Vectorizer] Support predication of div/rem

div/rem instructions in basic blocks that require predication currently prevent
vectorization. This patch extends the existing mechanism for predicating stores
to handle other instructions and leverages it to predicate divs and rems.

Differential Revision: https://reviews.llvm.org/D22918

llvm-svn: 279620

[X86][SSE] Add support for 32-bit element vectors to X86ISD::VZEXT_LOAD

Consecutive load matching (EltsFromConsecutiveLoads) currently uses VZEXT_LOAD (load scalar into lowest element and zero uppers) for vXi64 / vXf64 vectors only.

For vXi32 / vXf32 vectors it instead creates a scalar load, SCALAR_TO_VECTOR and finally VZEXT_MOVL (zero upper vector elements), relying on tablegen patterns to match this into an equivalent of VZEXT_LOAD.

This patch adds the VZEXT_LOAD patterns for vXi32 / vXf32 vectors directly and updates EltsFromConsecutiveLoads to use this.

This has proven necessary to allow us to easily make VZEXT_MOVL a full member of the target shuffle set - without this change the call to combineShuffle (which is the main caller of EltsFromConsecutiveLoads) tended to recursively recreate VZEXT_MOVL nodes......

Differential Revision: https://reviews.llvm.org/D23673

llvm-svn: 279619

[PM] Introduce basic update capabilities to the new PM's CGSCC pass
manager, including both plumbing and logic to handle function pass
updates.

There are three fundamentally tied changes here:
1) Plumbing *some* mechanism for updating the CGSCC pass manager as the
   CG changes while passes are running.
2) Changing the CGSCC pass manager infrastructure to have support for
   the underlying graph to mutate mid-pass run.
3) Actually updating the CG after function passes run.

I can separate them if necessary, but I think its really useful to have
them together as the needs of #3 drove #2, and that in turn drove #1.

The plumbing technique is to extend the "run" method signature with
extra arguments. We provide the call graph that intrinsically is
available as it is the basis of the pass manager's IR units, and an
output parameter that records the results of updating the call graph
during an SCC passes's run. Note that "...UpdateResult" isn't a *great*
name here... suggestions very welcome.

I tried a pretty frustrating number of different data structures and such
for the innards of the update result. Every other one failed for one
reason or another. Sometimes I just couldn't keep the layers of
complexity right in my head. The thing that really worked was to just
directly provide access to the underlying structures used to walk the
call graph so that their updates could be informed by the *particular*
nature of the change to the graph.

The technique for how to make the pass management infrastructure cope
with mutating graphs was also something that took a really, really large
number of iterations to get to a place where I was happy. Here are some
of the considerations that drove the design:

- We operate at three levels within the infrastructure: RefSCC, SCC, and
  Node. In each case, we are working bottom up and so we want to
  continue to iterate on the "lowest" node as the graph changes. Look at
  how we iterate over nodes in an SCC running function passes as those
  function passes mutate the CG. We continue to iterate on the "lowest"
  SCC, which is the one that continues to contain the function just
  processed.

- The call graph structure re-uses SCCs (and RefSCCs) during mutation
  events for the *highest* entry in the resulting new subgraph, not the
  lowest. This means that it is necessary to continually update the
  current SCC or RefSCC as it shifts. This is really surprising and
  subtle, and took a long time for me to work out. I actually tried
  changing the call graph to provide the opposite behavior, and it
  breaks *EVERYTHING*. The graph update algorithms are really deeply
  tied to this particualr pattern.

- When SCCs or RefSCCs are split apart and refined and we continually
  re-pin our processing to the bottom one in the subgraph, we need to
  enqueue the newly formed SCCs and RefSCCs for subsequent processing.
  Queuing them presents a few challenges:
  1) SCCs and RefSCCs use wildly different iteration strategies at
     a high level. We end up needing to converge them on worklist
     approaches that can be extended in order to be able to handle the
     mutations.
  2) The order of the enqueuing need to remain bottom-up post-order so
     that we don't get surprising order of visitation for things like
     the inliner.
  3) We need the worklists to have set semantics so we don't duplicate
     things endlessly. We don't need a *persistent* set though because
     we always keep processing the bottom node!!!! This is super, super
     surprising to me and took a long time to convince myself this is
     correct, but I'm pretty sure it is... Once we sink down to the
     bottom node, we can't re-split out the same node in any way, and
     the postorder of the current queue is fixed and unchanging.
  4) We need to make sure that the "current" SCC or RefSCC actually gets
     enqueued here such that we re-visit it because we continue
     processing a *new*, *bottom* SCC/RefSCC.

- We also need the ability to *skip* SCCs and RefSCCs that get merged
  into a larger component. We even need the ability to skip *nodes* from
  an SCC that are no longer part of that SCC.

This led to the design you see in the patch which uses SetVector-based
worklists. The RefSCC worklist is always empty until an update occurs
and is just used to handle those RefSCCs created by updates as the
others don't even exist yet and are formed on-demand during the
bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and
we push new SCCs onto it and blacklist existing SCCs on it to get the
desired processing.

We then *directly* update these when updating the call graph as I was
never able to find a satisfactory abstraction around the update
strategy.

Finally, we need to compute the updates for function passes. This is
mostly used as an initial customer of all the update mechanisms to drive
their design to at least cover some real set of use cases. There are
a bunch of interesting things that came out of doing this:

- It is really nice to do this a function at a time because that
  function is likely hot in the cache. This means we want even the
  function pass adaptor to support online updates to the call graph!

- To update the call graph after arbitrary function pass mutations is
  quite hard. We have to build a fairly comprehensive set of
  data structures and then process them. Fortunately, some of this code
  is related to the code for building the cal graph in the first place.
  Unfortunately, very little of it makes any sense to share because the
  nature of what we're doing is so very different. I've factored out the
  one part that made sense at least.

- We need to transfer these updates into the various structures for the
  CGSCC pass manager. Once those were more sanely worked out, this
  became relatively easier. But some of those needs necessitated changes
  to the LazyCallGraph interface to make it significantly easier to
  extract the changed SCCs from an update operation.

- We also need to update the CGSCC analysis manager as the shape of the
  graph changes. When an SCC is merged away we need to clear analyses
  associated with it from the analysis manager which we didn't have
  support for in the analysis manager infrsatructure. New SCCs are easy!
  But then we have the case that the original SCC has its shape changed
  but remains in the call graph. There we need to *invalidate* the
  analyses associated with it.

- We also need to invalidate analyses after we *finish* processing an
  SCC. But the analyses we need to invalidate here are *only those for
  the newly updated SCC*!!! Because we only continue processing the
  bottom SCC, if we split SCCs apart the original one gets invalidated
  once when its shape changes and is not processed farther so its
  analyses will be correct. It is the bottom SCC which continues being
  processed and needs to have the "normal" invalidation done based on
  the preserved analyses set.

All of this is mostly background and context for the changes here.

Many thanks to all the reviewers who helped here. Especially Sanjoy who
caught several interesting bugs in the graph algorithms, David, Sean,
and others who all helped with feedback.

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

llvm-svn: 279618

Canonicalize output section name for .ARM.exidx sections

The ARM Exception handling ABI requires that all ARM exception index
table sections have a prefix of .ARM.exidx and are combined into a
single contiguous block either in their own output section or as part
of another output section.

In general clang will output a single .ARM.exidx section per object,
but will use .ARM.exidx.<section name> when -ffunction-sections is used.

This change canonicalizes the names of sections with the .ARM.exidx
prefix to just .ARM.exidx, which ensures that there is only a single
output section.

Differential Revision: https://reviews.llvm.org/D23775

llvm-svn: 279617

[asan] Mark asan-symbolize-sanity-test.cc as UNSUPPORTED on x86_64-apple
and x86_64h-apple.

Mark the test as UNSUPPORTED to fix a bot that is failing.

http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check

The bot is failing because asan_symbolize.py cannot tell whether the
reported address is from an x86_64 slice or an x86_64h slice by the
length of the address alone, so it ends up passing the wrong arch to
atos.

rdar://problem/27907889

llvm-svn: 279614

[AST] Make InitListExpr::isExplicit const (NFC)

Patch by Alexander Shaposhnikov!

Differential Revision: https://reviews.llvm.org/D23828

llvm-svn: 279613

Tentatively fix gold-plugin test: ThinLTO objects start at offset 0 now.

Annoyingly, incremental builds don't detect these kind of issue.

llvm-svn: 279612

Add api logging for SBDebugger::SetCurrentPlatformSDKRoot.
<rdar://problem/27857025>

llvm-svn: 279611

[Coroutines] Fix unused var warning in release build

llvm-svn: 279610

[Coroutines] Part 8: Coroutine Frame Building algorithm

Summary:
This patch adds coroutine frame building algorithm. Now, simple coroutines such as ex0.ll and ex1.ll (first examples from docs\Coroutines.rst can be compiled).

Documentation and overview is here: http://llvm.org/docs/Coroutines.html.

Upstreaming sequence (rough plan)
1.Add documentation. (https://reviews.llvm.org/D22603)
2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659)
...

7. Split coroutine into subfunctions. (https://reviews.llvm.org/D23461)
8. Coroutine Frame Building algorithm  <= we are here
9. Add f.cleanup subfunction.
10+. The rest of the logic

Reviewers: majnemer

Subscribers: mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D23586

llvm-svn: 279609

[Pragma] Clear loop distribution attribute between loops

llvm-svn: 279608

Remove excessive padding from PTHStatData (NFC)

This diff reorders the fields and removes excessive padding.
This fixes the following warning:

PTHLexer.cpp:629:7: warning: Excessive padding in 'class (anonymous namespace)::PTHStatData' (14 padding bytes, where 6 is optimal). Optimal fields order: Size, ModTime, UniqueID, HasData, IsDirectory, consider reordering the fields or adding explicit padding members.

Patch by: Alexander Shaposhnikov <shal1t712@gmail.com>

Differential Revision: https://reviews.llvm.org/D23826

llvm-svn: 279607

libc++: add an option to build against compiler-rt

This mirrors the option in libc++abi to build without libgcc.

llvm-svn: 279606

Preserve a pointer to the newly allocated signal stack as well. That too
is flagged by LSan at least among leak detectors.

llvm-svn: 279605

TargetSchedule: Do not consider subregister definitions as reads.

We should not consider subregister definitions as reads for schedule
model purposes (they are just modeled as reads of the overal vreg for
liveness calculation purposes, the CPU instructions are not actually
reading).

Unfortunately I cannot submit a test for this as it requires a target
which uses ReadAdvance annotation in the scheduling model and has
subregister liveness enabled at the same time, which is only the case on
an out of tree target.

llvm-svn: 279604

Adding an additional test to ensure the frame pointer is emitted
when compiling with optimization when PS4 is the target.

llvm-svn: 279603

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this patch, hopefully I will get away without any warnings
in the constructor now.

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.

This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.

Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.

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

llvm-svn: 279602

[libFuzzer] use __attribute__((target("popcnt"))) only on x86_64

llvm-svn: 279601

MIRParser/MIRPrinter: Compute isSSA instead of printing/parsing it.

Specifying isSSA is an extra line at best and results in invalid MI at
worst. Compute the value instead.

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

llvm-svn: 279600

Increase the size of the sigaltstack used by LLVM signal handlers. 8KB is not
sufficient in some cases; increase to 64KB, which should be enough for anyone :)

Patch by github.com/bryant!

llvm-svn: 279599

MachineModuleInfo: Avoid dummy constructor, use INITIALIZE_TM_PASS

Change this pass constructor to just accept a const TargetMachine * and
use INITIALIZE_TM_PASS, that way we can get rid of the dummy
constructor. The pass will still fail when calling the default
constructor leading to TM == nullptr, this is no different than before
but is more in line what other codegen passes are doing and avoids the
dummy constructor.

llvm-svn: 279598

Revert "libc++: Perform configuration checks with -nodefaultlibs"

This reverts SVN r279584 which broke the buildbots.  Will re-apply once the
issue has been root-caused and fixed.

llvm-svn: 279596

[sanitizer] trying to fix the PPC bots

llvm-svn: 279595

[ADCE] Add control dependence computation

Summary:
This is part of a serious of patches to evolve ADCE.cpp to support
removing of unnecessary control flow.

This patch adds the ability to compute control dependences using
the iterated dominance frontier. We extend the liveness propagation
to alternate between data and control dependences until convergences.

Modify the pass manager intergation to compute the post-dominator tree
needed for iterator dominance frontier.

We still force all terminators live for now until we add code to
handlinge removing control flow in a later patch.

No changes to effective behavior with this patch

Previous patches:

D23225 [ADCE] Modify data structures to support removing control flow
D23065 [ADCE] Refactor anticipating new functionality (NFC)
D23102 [ADCE] Refactoring for new functionality (NFC)

Reviewers: nadav, majnemer, mehdi_amini

Subscribers: twoh, freik, llvm-commits

Differential Revision: https://reviews.llvm.org/D23559

llvm-svn: 279594

[stackmaps] Remove an unneeded member variable [NFC]

llvm-svn: 279590

[libFuzzer] fix link in docs

llvm-svn: 279589

[libFuzzer] collect 64 states for value profile, not 65

llvm-svn: 279588

[libFuzzer] docs on value profile

llvm-svn: 279587

[stackmaps] More extraction of common code [NFCI]

General cleanup before starting to work on the part I want to actually change.

llvm-svn: 279586

[LoopUnroll] By default disable unrolling when optimizing for size.

Summary:
In clang commit r268509 we started to invoke loop-unroll pass from the
driver even under -Os. However, we happen to not initialize optsize
thresholds properly, which si fixed with this change.

r268509 led to some big compile time regressions, because we started to
unroll some loops that we didn't unroll before. With this change I hope
to recover most of the regressions. We still are slightly slower than
before, because we do some checks here and there in loop-unrolling
before we bail out, but at least the slowdown is not that huge now.

Reviewers: hfinkel, chandlerc

Subscribers: mzolotukhin, llvm-commits

Differential Revision: https://reviews.llvm.org/D23388

llvm-svn: 279585

libc++: Perform configuration checks with -nodefaultlibs

We're compiling libc++ with -nodefaultlibs, so we should also pass this option
during the configuration checks to ensure those checks are consistent with the
actual build.

The primary motivation here is to ease cross-compilation against a non-standard
set of C++ libraries. Previously, the configuration checks would attempt to link
against the standard C++ libraries, which would cause link failures when
cross-compiling, even though the actual library link would go through correctly
(because of the use of -nodefaultlibs and explicitly specifying any needed
libraries). This is more correct even ignoring the motivation, however.

Patch by Shoaib Meenai!

llvm-svn: 279584

Don't use "return {...}" to initialize a std::tuple. This has only been valid
since 2015 (n4387), though it's allowed by a library DR so new implementations
accept it in their C++11 modes...

This should unbreak the build with libstdc++ 4.9.

llvm-svn: 279583

#ifdef out validation code when asserts are disabled to remove unused variable
warnings.

llvm-svn: 279582

Remove unused data member to unbreak -Werror builds.

llvm-svn: 279581

Revert r279564. It introduces undefined behavior (binding a reference to a
dereferenced null pointer) in MachineModuleInfo::MachineModuleInfo that causes
-Werror builds (including several buildbots) to fail.

llvm-svn: 279580

GlobalISel: add some G_TRUNCs to make icmp test valid MIR.

llvm-svn: 279579

[InstCombine] use local variables for repeated values; NFCI

llvm-svn: 279578

[MC] Support .dc directives in assembler parser

While these directives are mostly aliases for the existing integer
and float value directives, some of them like .dc.a have no direct
equivalents and are sometimes being used for convenience.

Differential Revision: https://reviews.llvm.org/D23810

llvm-svn: 279577

[ThinLTO] Add caching to the new LTO API

Add the ability to plug a cache on the LTO API.
I tried to write such that a linker implementation can
control the cache backend. This is intrusive and I'm
not totally happy with it, but I can't figure out a
better design right now.

Differential Revision: https://reviews.llvm.org/D23599

llvm-svn: 279576

[InstCombine] move foldICmpShrConstConst() contents to foldICmpShrConst(); NFCI

There will only be 3 lines of code in foldICmpShrConst() when the cleanup is done,
so it doesn't make much sense to have a separate function for a single fold.

llvm-svn: 279575

[stackmaps] Extract out magic constants [NFCI]

This is a first step towards clarifying the exact MI semantics of stackmap's "live values".

llvm-svn: 279574

MachineFunction: Introduce NoPHIs property

I want to compute the SSA property of .mir files automatically in
upcoming patches. The problem with this is that some inputs will be
reported as static single assignment with some passes claiming not to
support SSA form.  In reality though those passes do not support PHI
instructions => Track the presence of PHI instructions separate from the
SSA property.

Differential Revision: https://reviews.llvm.org/D22719

llvm-svn: 279573

[sanitizer] change the 64-bit allocator to use a single array for free-d chunks instead of a lock-free linked list of tranfer batches. This change simplifies the code, makes the allocator more 'hardened', and will allow simpler code to release RAM to OS. This may also slowdown malloc stress tests due to lock contension, but I did not observe noticeable slowdown on various real multi-threaded benchmarks.

llvm-svn: 279572

Fix member call on null pointer, found by sanitizer buildbot.

llvm-svn: 279571

[sanitizer] adding a threaded performance stress test for malloc (useful for manual analysis of malloc performance)

llvm-svn: 279570

GlobalISel: add forgotten test-case for G_ICMP

llvm-svn: 279569

[InstCombine] remove icmp shr folds that are already handled by InstSimplify

AFAICT, these already worked in all cases for scalar types, and I enhanced
the code to work for vector types in:
https://reviews.llvm.org/rL279543

llvm-svn: 279568

GlobalISel: make truncate/extend casts uniform

They really should have both types represented, but early variants were created
before MachineInstrs could have multiple types so they're rather ambiguous.

llvm-svn: 279567

GlobalISel: legalize integer comparisons on AArch64.

Next step is doing both legalizations at the same time! Marvel at GlobalISel's
cunning.

llvm-svn: 279566

GlobalISel: legalize conditional branches on AArch64.

llvm-svn: 279565

CodeGen: Remove MachineFunctionAnalysis => Enable (Machine)ModulePasses

Re-apply this commit with the deletion of a MachineFunction delegated to
a separate pass to avoid use after free when doing this directly in
AsmPrinter.

This patch removes the MachineFunctionAnalysis. Instead we keep a
map from IR Function to MachineFunction in the MachineModuleInfo.

This allows the insertion of ModulePasses into the codegen pipeline
without breaking it because the MachineFunctionAnalysis gets dropped
before a module pass.

Peak memory should stay unchanged without a ModulePass in the codegen
pipeline: Previously the MachineFunction was freed at the end of a codegen
function pipeline because the MachineFunctionAnalysis was dropped; With
this patch the MachineFunction is freed after the AsmPrinter has
finished.

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

llvm-svn: 279564

[ValueTracking] Use a function_ref to avoid multiple instantiations

No functional change intended, this should just be a code size
improvement.

llvm-svn: 279563

[SLP] Avoid signed integer overflow

The test case included with r279125 exposed an existing signed integer
overflow. Since getTreeCost can return INT_MAX, we can't sum this cost together
with other costs, such as getReductionCost.

This patch removes the possibility of assigning a cost of INT_MAX. Since we
were previously using INT_MAX as an indicator for "should not vectorize", we
now explicitly check this condition with "isTreeTinyAndNotFullyVectorizable"
before computing a cost.

This patch adds a run-line to the test case used for r279125 that ensures we
don't vectorize. Previously, this line would vectorize the test case by chance
due to undefined behavior in the cost calculation.

Differential Revision: https://reviews.llvm.org/D23723

llvm-svn: 279562

Remove unused translation unit.

llvm-svn: 279561

Update coding standards for include style.

Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D23591

llvm-svn: 279560

driver: Support checking for rlimits via cmake (when bootstrapping)

Summary:
Add a cmake check for sys/resource.h and replace the __has_include() check with its result, in order to make it possible to use rlimits when building with compilers not supporting __has_include() -- i.e. when bootstrapping.

// Please also re-apply dfcd52eb1d8e5d322404b40414cb7331c7380a8c (llvm-config.h fix)

Patch by: Michał Górny

Reviewers: rsmith, beanz

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D23744

llvm-svn: 279559

Remove two dos line endings.

llvm-svn: 279558

Fix regression introduced by r279164: only pass definitions as the PatternDef
to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
determine whether a function definition is visible, and mark both the function
and the template as visible when merging function template definitions to
provide hasVisibleDefinition with the relevant information.

The change to always pass the right declaration as the PatternDef to
DiagnoseUninstantiableTemplate also caused those checks to happen before other
diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for the
same situations, so I sunk the relevant diagnostics into
DiagnoseUninstantiableTemplate. Those parts of this patch are based on changes
in reviews.llvm.org/D23492 by Vassil Vassilev.

This reinstates r279486, reverted in r279500, with a fix to
DiagnoseUninstantiableTemplate to only mark uninstantiable explicit
instantiation declarations as invalid if we actually diagnosed them. (When we
trigger an explicit instantiation of a class member from an explicit
instantiation declaration for the class, it's OK if there is no corresponding
definition and we certainly don't want to mark the member invalid in that
case.) This previously caused a build failure during bootstrap.

llvm-svn: 279557

[LTO] Fix test following r279550

The output name changed, but it was passing locally
using the old output still present in the build dir.

llvm-svn: 279556

clang-cl: Make /Brepro actually work.

/Brepro means we want reproducible builds, i.e. we _don't_ want the timestamp
that's needed to be compatible with the incremental linker.

https://reviews.llvm.org/D23805

llvm-svn: 279555

GlobalISel: extend legalizer interface to handle multiple types.

Instructions like G_ICMP have multiple types that may need to be legalized (the
boolean output and nearly arbitrary inputs in this case). So the legalizer must
be capable of deciding what to do for each of them separately.

llvm-svn: 279554

GlobalISel: mark pointer casts legal on AArch64.

llvm-svn: 279553

libcxx: Fix libcxx tests on aarch64 with libunwind

Some tests uses 'long double' to/from conversions and for some targets
they are provided by compiler runtime (either compiler-rt or libgcc).
However when building libcxx with linunwinder current test configuration
at target_info.py do not include the required libraries, as:

  not llvm_unwinder:
    "-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc"

  llvm_unwinder
    "-lc++" "-lm" "-lpthread" "-lc" "-lunwind" "-ldl"

This causes some tests build issues with missing symbols on aarch64,
for instance, where 'long double' is a binary float with 128-bits with
mostly of internal operations being provided by software routines.

This patch changes how to define the default linker flags with libunwinder by
adding libgcc regardless.

I checked and aarch64 and x86_64 with libcxx and libunwind (with and without
LIBCXXABI_USE_LLVM_UNWINDER).

llvm-svn: 279552

[ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)

This adds a test for r279532, thanks David Li for noticing :)

Recommit r279545 after committing first a dependent patch.

llvm-svn: 279551

Stop always creating and running an LTO compilation if there is not a single LTO object

Summary:
I assume there was a use case, so maybe this strawman patch will help
clarifying if it is legit.
In any case the current situation is not legit: a ThinLTO compilation
should not trigger an unexpected full LTO compilation.
Right now, adding a --save-temps option triggers this and makes the
number of output differs.

Reviewers: tejohnson

Subscribers: pcc, llvm-commits, mehdi_amini

Differential Revision: https://reviews.llvm.org/D23600

llvm-svn: 279550

Revert "[ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)"

This reverts commit r279545, test is failing, my Output dir was dirty and making the test pass.

llvm-svn: 279549

GlobalISel: legalize 1-bit load/store and mark 8/16 bit variants legal on AArch64.

llvm-svn: 279548

[asan] minor fix in the asan memory profile

llvm-svn: 279547

ARM-Darwin: ignore and diagnose attempts to omit frame pointer.

iOS (and other 32-bit ARM variants) always require a valid frame pointer to
improve backtraces. Previously the -fomit-frame-pointer and
-momit-leaf-frame-pointer options were being silently discarded via hacks in
the backend. It's better if Clang configures itself to emit the correct IR and
warns about (ignored) attempts to override this.

llvm-svn: 279546

[ThinLTO] Add a llvm-lto2 test to check that ODR type uniquing is enabled (NFC)

This adds a test for r279532, thanks David Li for noticing :)

llvm-svn: 279545

[CMake] [OCaml] Add -DLLVM_ENABLE_OCAMLDOC switch

Patch by Michael Gorny.

llvm-svn: 279544

[InstSimplify] allow icmp with constant folds for splat vectors, part 2

Completes the m_APInt changes for simplifyICmpWithConstant().

Other commits in this series:
https://reviews.llvm.org/rL279492
https://reviews.llvm.org/rL279530
https://reviews.llvm.org/rL279534
https://reviews.llvm.org/rL279538

llvm-svn: 279543

Possible fix of test failures on win bots

llvm-svn: 279542

[Documentation] Fix style of Clang-tidy readability-non-const-parameter.

llvm-svn: 279541

Implementation "step out" plans shouldn't gather the return value.

When, for instance, "step-in" steps into a function that it doesn't want
to stop in (e.g. has no debug info) it will push a step-out plan to implement
the step out so it can then continue stepping.  These step out's don't use
the result of the function stepped out of, so they shouldn't spend the time
to compute it.

llvm-svn: 279540

Delete remaining compiler-rt makefiles

Summary:
Since we can now build the builtins without a full toolchain these files should no longer be needed.

This is the last vestige of autoconf!

Reviewers: compnerd, iains, jroelofs

Subscribers: dberris, llvm-commits

Differential Revision: https://reviews.llvm.org/D23777

llvm-svn: 279539

[InstSimplify] allow icmp with constant folds for splat vectors, part 1

llvm-svn: 279538

[SelectionDAG] Use a union of bitfield structs for SDNode::SubclassData.

Summary:
This greatly simplifies our handling of SDNode::SubclassData.

NFC, hopefully.  :)

See discussion in D23035 for discussion about the design API of these
bitfields.

Reviewers: chandlerc

Subscribers: llvm-commits, rnk

Differential Revision: https://reviews.llvm.org/D23036

llvm-svn: 279537

[CodeGen] Convert a loop to a for-each loop. NFC

llvm-svn: 279536

Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes.

Differential revision: https://reviews.llvm.org/D23789

llvm-svn: 279535

[InstSimplify] add tests to show missing vector icmp folds

llvm-svn: 279534

Change the PathMappingList::FindFile to use FileSpec API's

Also, when appending path components, collapse multiple "/" into one at the join.

llvm-svn: 279533

[ThinLTO] Make sure the Context used for the ThinLTO backend has all the appropriate options

An important performance setting on the LLVMContext for LTO is
enableDebugTypeODRUniquing(), this adds an automatic merging of
debug information in the context based on type ids.

Also, the lto::Config includes a diagnostic handler that needs to
be set on the Context, as well as the setDiscardValueNames() setting.

llvm-svn: 279532

clang-cl: Accept MSVC 2015's `/source-charset:utf-8` flag.

clang already treats all inputs as utf-8. Warn if anything but utf-8 is passed.

Do this by mapping source-charset to finput-charset, which already behaves like
this. Slightly tweak finput-charset to accept "utf-8" case-insensitively. This
matches gcc's and cl.exe's behavior, and IANA says that character set names are
case-insensitive.

https://reviews.llvm.org/D23807

llvm-svn: 279531

[InstSimplify] move icmp with constant tests to another file; NFC

...because like the corresponding code, this is just too big to keep adding to.
And the next step is to add a vector version of each of these tests to show
missed folds.

Also, auto-generate CHECK lines and add comments for the tests that correspond to
the source code.

llvm-svn: 279530

[analyzer] Fix CloneDetector crash on calling methods of class templates.

If a call expression represents a method call of a class template,
and the method itself isn't templated, then the method may be considered
to be a template instantiation without template specialization arguments.

No longer crash when we could not find template specialization arguments.

Patch by Raphael Isemann!

Differential Revision: https://reviews.llvm.org/D23780

llvm-svn: 279529

Fix some more asserts after r279466.

That commit added a new version of Intrinsic::getName which should only
be called when the intrinsic has no overloaded types.  There are several
debugging paths, such as SDNode::dump which are printing the name of the
intrinsic but don't have the overloaded types.  These paths should be ok
to just print the name instead of crashing.

The fix here is ultimately to just add a 'None' second argument as that
calls the overload capable getName, which is less efficient, but this is a
debugging path anyway, and not perf critical.

Thanks to Björn Pettersson for pointing out that there were more crashes.

llvm-svn: 279528

[X86][SSE] Demonstrate inability to recognise that (v)cvtpd2dq & (v)cvttpd2dq intrinsics implicitly zeroes the upper half of the xmm

llvm-svn: 279527

[Hexagon] Packetize return value setup with the return instruction

Commit r279241 unintentionally reverted that ability.

llvm-svn: 279526

Fix windows build failure

llvm-svn: 279525

Rename unittests/ADT/ilistTest.cpp to ilistTestTemp.cpp (temporarily)

I'll rename this to IListTest.cpp after a waiting period (tonight?
tomorrow?), with a full explanation in that commit.

First, I'm moving it aside because Git doesn't play well with case-only
filename changes on case-insensitive file systems (and I suspect the
same is true of SVN).  This two-stage change should help to avoid
spurious failures on bots that don't do clean checkouts.

llvm-svn: 279524

[Profile] refactor meta data copying/swapping code

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

llvm-svn: 279523