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).
746b78de78
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
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
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
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
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
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
When rL336971 removed the scalar-fp isel patterns, we lost the need for this canonicalization - commutation/folding can handle everything else.
llvm-svn: 337387
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
While working on PR38197, I noticed that we don't make use of FADD/FMUL being able to commute the inputs to support the addps+movss -> addss style combine
llvm-svn: 337375
This reverts commit 55222c9183c6e07f53a54c4061677734f54feac1.
I missed that this patch has a dependency on https://reviews.llvm.org/D49219
that has not been approved yet.
llvm-svn: 337373
The signed/unsigned DOT instructions perform a dot-product on
quadtuplets from two source vectors and accumulate the result in
the destination register. The instructions come in two forms:
Vector form, e.g.
sdot z0.s, z1.b, z2.b - signed dot product on four 8-bit quad-tuplets,
accumulating results in 32-bit elements.
udot z0.d, z1.h, z2.h - unsigned dot product on four 16-bit quad-tuplets,
accumulating results in 64-bit elements.
Indexed form, e.g.
sdot z0.s, z1.b, z2.b[3] - signed dot product on four 8-bit quad-tuplets
with specified quadtuplet from second
source vector, accumulating results in 32-bit
elements.
udot z0.d, z1.h, z2.h[1] - dot product on four 16-bit quad-tuplets
with specified quadtuplet from second
source vector, accumulating results in 64-bit
elements.
llvm-svn: 337372
Erich Keane