| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
If -z stack-size is given, we need to add PT_GNU_STACK even if
-z execstack is not given.
llvm-svn: 295945
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While porting libunwind over to CloudABI for ARMv6, I observed that this
source file doesn't build, as it depends on dl_unwind_find_exidx(),
which CloudABI's C library was lacking. After I added that function,
I still needed to patch up libunwind to define _Unwind_Ptr.
Taking a step back, I wonder why we need to make use of this function
anyway. The unwinder already has some nice code to use dl_iterate_phdr()
to scan for a PT_GNU_EH_FRAME header. The dl_unwind_find_exidx() does
the same thing, except matching PT_ARM_EXIDX instead. We could also do
that ourselves.
This change gets rid of the dl_unwind_find_exidx() call and extends the
dl_iterate_phdr() loop. In addition to making the code a bit shorter, it
has the advantage of getting rid of some of those OS-specific #ifdefs.
This now means that if an operating system only provides
dl_iterate_phdr(), it gets support for unwinding on all architectures.
There is no need to add more stuff, just to get ARMv6 support.
Differential Revision: https://reviews.llvm.org/D28082
llvm-svn: 295944
|
| |
|
|
|
|
| |
Thanks to Rui Ueyama for suggestion.
llvm-svn: 295943
|
| |
|
|
| |
llvm-svn: 295942
|
| |
|
|
| |
llvm-svn: 295941
|
| |
|
|
|
|
|
|
|
|
| |
between VEX/EVEX versions.
AVX versions of the converts work on f32/f64 types, while AVX512 version work on vectors.
Differential Revision: https://reviews.llvm.org/D29988
llvm-svn: 295940
|
| |
|
|
| |
llvm-svn: 295939
|
| |
|
|
| |
llvm-svn: 295938
|
| |
|
|
|
|
|
|
| |
We have InputSection, MergeInputSection and EhInputSection, so
isa<MergeInputSection> is equivalent to !isa<InputSection> && !isa<
EhInputSection>.
llvm-svn: 295937
|
| |
|
|
|
|
|
|
|
| |
We shouldn't report an error for R_*_NONE relocs since we're emitting
them when writing relocations to discarded sections.
Differential Revision: https://reviews.llvm.org/D30279
llvm-svn: 295936
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an assertion failure in cases where we had expression
statements that declared variables nested inside of pass_object_size
args. Since we were emitting the same ExprStmt twice (once for the arg,
once for the @llvm.objectsize call), we were getting issues with
redefining locals.
This also means that we can be more lax about when we emit
@llvm.objectsize for pass_object_size args: since we're reusing the
arg's value itself, we don't have to care so much about side-effects.
llvm-svn: 295935
|
| |
|
|
|
|
| |
It's unnecessary.
llvm-svn: 295934
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement isLegalToVectorizeLoadChain for AMDGPU to avoid
producing private address spaces accesses that will need to be
split up later. This was doing the wrong thing in the case
where the queried chain was an even number of elements.
A possible <4 x i32> store was being split into
store <2 x i32>
store i32
store i32
rather than
store <2 x i32>
store <2 x i32>
when legal.
llvm-svn: 295933
|
| |
|
|
| |
llvm-svn: 295932
|
| |
|
|
|
|
|
|
|
|
| |
Fields will now have their types added to the hash, allowing for detection of
mismatched field types. This detection allows the existing ODR checking to
produce the correct message.
Differential Revision: https://reviews.llvm.org/D21675
llvm-svn: 295931
|
| |
|
|
|
|
|
|
|
|
| |
instead of anything starting with xop.vpcmov
There were some older intrinsics that only existed for less than a month in 2012 that still exist in some out of tree test files that start with this string, but aren't able to be handled by the current upgrade code and fire an assert. Now we'll go back to treating them as not intrinsics at all and just passing them through to output.
Fixes PR32041, sort of.
llvm-svn: 295930
|
| |
|
|
| |
llvm-svn: 295929
|
| |
|
|
| |
llvm-svn: 295928
|
| |
|
|
|
|
| |
This shouldn't change the meaning of the code.
llvm-svn: 295927
|
| |
|
|
| |
llvm-svn: 295926
|
| |
|
|
| |
llvm-svn: 295925
|
| |
|
|
|
|
|
| |
Now that InputSectionBase is not a template there is no reason to have
the two.
llvm-svn: 295924
|
| |
|
|
|
|
|
| |
Removing this template is not a big win by itself, but opens the way
for removing more templates.
llvm-svn: 295923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.
This patch makes build-llvm.py consult a directory full
of .json files, each one of which matches a particular
branch using a regular expression.
This update to the patch introduces a FALLBACK file
whose contents take precedence if the current branch
could not be identified. If the current branch could be
identified, FALLBACK is updated, allowing the user to
e.g. cut branches off of known branches and still have
the automatic checkout mechanism work.
It also documents all of this.
Differential revision: https://reviews.llvm.org/D30275
llvm-svn: 295922
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the current one.
Rather than attempting to compare whether the previous and current top of
context stack are "equal" (which fails for a number of reasons, such as the
context stack entries containing pointers to objects on the stack, or reaching
the same "top of stack" entry through two different paths), track the depth of
context stack at which we last emitted a note and invalidate it when we pop the
context stack to less than that depth.
This causes us to emit some missing "in instantiation of" notes and to stop
emitting redundant "in instantiation of" stacks matching the previous stack in
rare cases.
llvm-svn: 295921
|
| |
|
|
|
|
|
|
|
|
| |
Trivially define native_tan as a redirect to tan.
If there are any targets with a native implementation, we can deal with it later.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <arsenm2@gmail.com>
llvm-svn: 295920
|
| |
|
|
|
|
|
| |
using it for other kinds of context (where we currently produce context notes
in a highly ad-hoc manner).
llvm-svn: 295919
|
| |
|
|
| |
llvm-svn: 295918
|
| |
|
|
| |
llvm-svn: 295917
|
| |
|
|
|
|
|
|
|
| |
See https://llvm.org/bugs/show_bug.cgi?id=31439; this reflects LLVM's
behavior in practice, and should be compatible with C/C++ rules.
Differential Revision: https://reviews.llvm.org/D28026
llvm-svn: 295916
|
| |
|
|
| |
llvm-svn: 295915
|
| |
|
|
| |
llvm-svn: 295914
|
| |
|
|
|
|
|
| |
Previously, bitcode files in library paths were passed to the MSVC linker.
This patch strips them.
llvm-svn: 295913
|
| |
|
|
|
|
|
| |
This is the pattern that falls out of the instruction's
definition if offset == 0.
llvm-svn: 295912
|
| |
|
|
|
|
|
|
|
| |
IdentifierInfo is hashed based on the stored string. FieldDecl versus other
Decl is now detected, as well as differently named fields.
Differential Revision: https://reviews.llvm.org/D21675
llvm-svn: 295911
|
| |
|
|
| |
llvm-svn: 295909
|
| |
|
|
| |
llvm-svn: 295908
|
| |
|
|
|
|
|
|
|
| |
- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block
<rdar://problem/30644888>
llvm-svn: 295907
|
| |
|
|
| |
llvm-svn: 295906
|
| |
|
|
|
|
|
|
|
|
|
| |
The manual is unclear on the details of this. It's not
clear to me if denormals are not allowed with clamp,
or if that is only omod. Not allowing denorms for
fp16 or fp64 isn't useful so I also question if that
is really a restriction. Same with whether this is valid
without IEEE mode enabled.
llvm-svn: 295905
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D30232
llvm-svn: 295904
|
| |
|
|
|
|
| |
rdar://30603803
llvm-svn: 295903
|
| |
|
|
|
|
| |
This test now passes on darwin.
llvm-svn: 295902
|
| |
|
|
|
|
| |
correctly.
llvm-svn: 295901
|
| |
|
|
|
|
|
| |
We need to investigate this, but for now it just causes too much
headache when trying to run these tests.
llvm-svn: 295900
|
| |
|
|
| |
llvm-svn: 295899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it's slow and unlikely to succeed
Notably, no regression tests change when we remove these calls, and these are expensive calls.
The motivation comes from the general acknowledgement that the compiler is getting slower:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109188.html
http://lists.llvm.org/pipermail/llvm-dev/2016-December/108279.html
And specifically the test case attached to PR32037:
https://bugs.llvm.org//show_bug.cgi?id=32037
Profiling the middle-end (opt) part of the compile:
$ ./opt -O2 row_common.bc -o /dev/null
...visitAdd and visitSub are near the top of the instcombine list, and the calls to SimplifyDemandedInstructionBits()
are high within each of those. Those calls account for 1%+ of the opt time in either debug or release profiles. And
that's the rough win I see from this patch when testing opt built release from r295864 on an iMac with Haswell 4GHz
(model 4790K).
It seems unlikely that we'd be able to eliminate add/sub or change their operands given that add/sub normally affect
all bits, and the PR32037 example shows no IR difference after this change using -O2.
Also worth noting - the code comment in visitAdd:
// This handles stuff like (X & 254)+1 -> (X&254)|1
...isn't true. That transform is handled later with a call to haveNoCommonBitsSet().
Differential Revision: https://reviews.llvm.org/D30270
llvm-svn: 295898
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLDB has many branches in a variety of repositories.
The build-script.py file is subtly different for each set.
This is unnecessary and causes merge headaches.
This patch makes build-llvm.py consult a directory full
of .json files, each one of which matches a particular
branch using a regular expression.
Differential revision: https://reviews.llvm.org/D30275
llvm-svn: 295897
|
| |
|
|
|
|
|
|
| |
Added virtual destructor in a class containing virtual functions.
Differential Revision: https://reviews.llvm.org/D30271
llvm-svn: 295896
|
| |
|
|
|
|
| |
Fixes the build.
llvm-svn: 295895
|