This patch uses CodeSegAttr to represent __declspec(code_seg) rather than 
building on the existing support for #pragma code_seg.
The code_seg declspec is applied on functions and classes. This attribute 
enables the placement of code into separate named segments, including compiler-
generated codes and template instantiations.

For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx

This patch fixes the regression for the support for attribute ((section).
https://github.com/llvm-mirror/clang/commit/746b78de7812bc785fbb5207b788348040b23fa7

Patch by Soumi Manna (Manna)
Differential Revision: https://reviews.llvm.org/D48841

llvm-svn: 337420

As discussed on PR38197, this canonicalizes MOVS*(N0, OP(N0, N1)) --> MOVS*(N0, SCALAR_TO_VECTOR(OP(N0[0], N1[0])))

This returns the scalar-fp codegen lost by rL336971.

Additionally it handles the OP(N1, N0)) case for commutable (FADD/FMUL) ops.

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

llvm-svn: 337419

Fuchsia doesn't have signals; instead it expects processes to have a
dedicated exception thread that binds to the process' exception port and
waits for exception packets to be delivered. On the other hand,
libFuzzer and sanitizer_common use expect to collect crash information
via libunwind from the same thread that caused the exception.

The long term fix is to improve support for remote unwinding in
libunbwind, plumb this through sanitizer_common and libFuzzer, and
handle the exception exclusively on the exception thread. In the
meantime, this revision has the exception thread "resurrect" the
crashing thread by:

* saving its general purpose register state onto the crashing thread's
  stack,
* setting the crashing thread's program counter to an assembly trampoline
  with the CFI information needed by libunwind, and
* resuming the crashed thread.

Patch By: aarongreen

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

llvm-svn: 337418

No functional change intended.

llvm-svn: 337417

Summary:
The optimizer is 10%+ slower with vs without debuginfo. I started checking where
the difference is coming from.

I compiled sqlite3.c with and without debug info from CTMark and compare the time difference.

I use Xcode Instrument to find where time is spent. This brings about 20ms, out of ~20s.

Reviewers: davide, hfinkel

Reviewed By: hfinkel

Subscribers: hfinkel, aprantl, JDevlieghere, llvm-commits

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

llvm-svn: 337416

This is very clearly not very good, and is very partial.
But this is better than nothing at all, and shouldn't
hurt those who don't need it.

If there are others interested in this functionality,
it will be great to further improve this.

{F6253091}

Reviewed By: Bigcheese

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

llvm-svn: 337415

llvm-svn: 337414

This reverts commit r336609 as it doesn't seem to work with AArch64
thunk creation when used with ASan.

llvm-svn: 337413

The 'safestack.c' test requires safestack as a dependency.

llvm-svn: 337412

Since DWARFv5 rnglists are self descriptive and have distinct encodings
for base-relative (offset_pair) and absolute (start_length) entries,
there's no need to use a base address specifier when describing a lone
address range in a section.

Use that, and improve the test coverage a bit here to include cases like
this and others.

llvm-svn: 337411

Summary:
Using _Atomic to do implicit load / store is just a seq_cst atomic_load / atomic_store. Stores currently assert in Sema::ImpCastExprToType with 'can't implicitly cast lvalue to rvalue with this cast kind', but that's erroneous. The codegen is fine as the test shows.

While investigating I found that Richard had found the problem here: https://reviews.llvm.org/D46112#1113557

<rdar://problem/40347123>

Reviewers: dexonsmith

Subscribers: cfe-commits, efriedma, rsmith, aaron.ballman

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

llvm-svn: 337410

Summary:
If unfolding an SUnit results in both load or the operation using it which
already exist in the DAG, abort the unfold if they are already scheduled.
If not, make sure we don't add duplicate dependencies.

This fixes PR37916.

Reviewers: davide, eli.friedman, fhahn, bogner

Subscribers: MatzeB, hiraditya, llvm-commits

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

llvm-svn: 337409

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

llvm-svn: 337408

Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=38018

Reviewers: thakis

Subscribers: llvm-commits

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

llvm-svn: 337407

llvm-svn: 337406

llvm-svn: 337405

Summary:
Updated and reorganized. Made the following additions:
1) How to see if ld.gold is installed, and whether it is the current
default.
2) How to install ld.gold as the default or alternatively use
-fuse-ld=gold.
3) Move the part about installing the newly built ld-new as the default
to the prior section and how to use --enable-gold=default to do it
automatically on install.
4) Add a note about ld.bfd supporting plugins but indicate that it is
not tested by the LLVM project and gold is the recommended linker for
use with the gold plugin.

Fixes PR32760.

Reviewers: davide

Subscribers: llvm-commits

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

llvm-svn: 337404

Summary:
Created IterateInline8bitCounters, a single template for visiting  Inline8bitCounters (nested for loop)
Made InitializeUnstableCounters and UpdateUnstableCounters both send a lambda to IterateInline8bitCounters.

Patch by Kyungtak Woo (@kevinwkt).

Reviewers: Dor1s, metzman, kcc, morehouse

Reviewed By: metzman, morehouse

Subscribers: delcypher, llvm-commits, #sanitizers

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

llvm-svn: 337403

llvm-svn: 337402

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

llvm-svn: 337401

At least one of these cases is more canonical,
so we really do have to handle it.
https://godbolt.org/g/pkzP3X
https://rise4fun.com/Alive/pQyh

llvm-svn: 337400

llvm-svn: 337399

Add missing .rep case in nestlevel checking for macro body parsing.

llvm-svn: 337398

Summary: This one fixes variables.test after D49018. The test was broken because D49018 adds a location information to variables, but I hadn't noticed that, because I used 32-bit build to run tests, so the test looked to me already broken before that commit (the test relies on mangled names, but the mangling schemes are different for 32-bit and 64-bit).

Reviewers: stella.stamenova, lldb-commits

Reviewed By: stella.stamenova

Patch By: Aleksandr Urakov

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

llvm-svn: 337397

For exmaple, clas field candidates in constructor initializers can be
RK_Pattern, but they can still have scopes.

llvm-svn: 337396

Summary: Right now we always try to retrieve ComSpec and if we fail, we give up. This rarely fails, but we can update the logic so that we fail even less frequently. Since there is a well-known path (albeit not always correct), try the path when we failed to retrieve it. Note that on other platforms, we generally just return a well-known path without any checking.

Reviewers: asmith, zturner, labath

Reviewed By: zturner, labath

Subscribers: llvm-commits

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

llvm-svn: 337395

Summary:
RK_Pattern results can also have associated declarations e.g. field
decls in constructor initializers.

Reviewers: bkramer

Subscribers: cfe-commits

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

llvm-svn: 337394

Summary: Several tests exist in both lit and lldbsuite. This removes the lit version of the duplicated tests.

Reviewers: asmith, zturner

Subscribers: llvm-commits

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

llvm-svn: 337393

This is a follow-up to the rL337171. This patch fixes regression
introduced by the r337171 and enables MipsTruncIntFP pattern.

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

llvm-svn: 337392

a Spectre v1 mitigation.

This was initially posted w/ the patch implementing this, got some basic
review there. Also, it is generated from a the Google doc that I shared
as part of the Speculative Load Hardening RFC and which has seen pretty
widespread review at this point.

However, as the patches are landing in LLVM, I wanted to land the docs
as well. But it seemed like a bad idea to have them in the same commit
in case of reverts or other things. So the docs are split out here.

Thanks for all the review so far, and further review and improvements to
the documentation here welcome. Please feel free to keep hammering on
the code review or Google document.

Note that this is a markdown document which Sphinx doesn't yet process.
But we can add support for that after and this should get picked up
(and I'm preparing patches for that). Also, this gets the document
itself into a nice shared place where we can iterate on it.

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

llvm-svn: 337391

Pulled out from D49225, we have a lot of repeated scalar cost calculations, often with arguments that don't look the same but turn out to be.

llvm-svn: 337390

Haiku does not expose information about local versus remote mounts, so just
return false, like Cygwin.

Patch by Niels Sascha Reedijk.

llvm-svn: 337389

llvm-svn: 337388

When rL336971 removed the scalar-fp isel patterns, we lost the need for this canonicalization - commutation/folding can handle everything else.

llvm-svn: 337387

Since the triple's default is hard float, the libcalls will already use VFP
registers.

llvm-svn: 337386

We were emitting incorrect calls to libm functions that LLVM had decided it
knew about because the default is soft-float.

llvm-svn: 337385

ARMSubtarget had a copy/pasted block to determine whether the target was
hard-float, but it just delegated to triple features anyway so it's better at
the TargetMachine level.

llvm-svn: 337384

This patch adds support for the following unpredicated
floating-point instructions:

  FADD      Floating point add
  FSUB      Floating point subtract
  FMUL      Floating point multiplication
  FTSMUL    Floating point trigonometric starting value
  FRECPS    Floating point reciprocal step
  FRSQRTS   Floating point reciprocal square root step

The instructions have the following assembly format:
  fadd z0.h, z1.h, z2.h
and have variants for 16, 32 and 64-bit FP elements.

llvm-svn: 337383

Currently, getFdePC() returns uint64_t. Its because the following
encodings might use 8 bytes: DW_EH_PE_absptr and DW_EH_PE_udata8.

But caller assigns returned value to uint32_t field:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L508

Value is used for building .eh_frame_hdr section.
We use DW_EH_PE_sdata4 encoding for building it at this moment:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2545

And that means that an overflow issue might happen if
DW_EH_PE_absptr/DW_EH_PE_udata8 address encodings are present
in .eh_frame. In that case, before this patch, we silently would
truncate the address and produced broken .eh_frame_hdr section.

It would be not hard to support real 64-bit values for
DW_EH_PE_absptr/DW_EH_PE_udata8 encodings, but it is
unclear if it is usefull and if we should do it.

Since nobody faced/reported it, int this patch I only implement
a check to stop producing broken output silently for now.

llvm-svn: 337382

llvm-svn: 337381