We were not previously testing the comdat exclusion in bitcode objects
because we were linking two copies of the .bc file and the
`linkonce_odr` linkage type was removing the duplicate `_start` at
the LTO stage.
Now we link an bitcode and non-bitcode version both of which contains a
copy of _start. We link them in both orders, which means this test will
fail if comdat exclusion is not working correctly in bitcode parsing.
Differential Revision: https://reviews.llvm.org/D62923
llvm-svn: 362650
One of the sources controls the pass through value for the upper bits
of the result so we can't really commute it.
In practice this problem isn't a functional issue because we would
only try to commute this instruction in order to fold a load. But
we can't do embedded rounding and fold a load at the same time. So
the load fold would never succeed so I don't think we would ever
commute or at least keep the version after commuting.
llvm-svn: 362647
With r362638, llc doesn't support -relocation-model=pic with non-Emscripten
triples. Update these tests in lld which use -relocation-model=pic to also
use Emscripten triples.
llvm-svn: 362645
When the byval attribute has a type, it must match the pointee type of
any parameter; but InstCombine was not updating the attribute when
folding casts of various kinds away.
llvm-svn: 362643
Most parts of LLVM don't care whether the byval type is derived from an
explicit Attribute or from the parameter's pointee type, so it makes
sense for the main access function to just return the right value.
The very few users who do care (only BitcodeReader so far) can find out
how it's specified by accessing the Attribute directly.
llvm-svn: 362642
The current PIC support currently only works with Emscripten, so
disable it for other targets.
This is the PIC portion of https://reviews.llvm.org/D62542.
Reviewed By: dschuff, sbc100
llvm-svn: 362638
Summary: This patch cleans up a duplicate use of TestingSupport library.
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62924
llvm-svn: 362637
Summary:
See D60593 for further information.
This patch introduces the core of GWP-ASan, being the guarded pool allocator. This class contains the logic for creating and maintaining allocations in the guarded pool. Its public interface is to be utilised by supporting allocators in order to provide sampled guarded allocation behaviour.
This patch also contains basic functionality tests of the allocator as unittests. The error-catching behaviour will be tested in upcoming patches that use Scudo as an implementing allocator.
Reviewers: vlad.tsyrklevich, eugenis, jfb
Reviewed By: vlad.tsyrklevich
Subscribers: dexonsmith, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, morehouse
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62872
llvm-svn: 362636
As far as I know these should be freely reassociatable just like
the floating point MAXC/MINC instructions.
The *reduce* test changes are largely regressions and caused by
the "generic" CPU we default to not having a scheduler model.
The machine-combiner-int-vec.ll test shows the positive benefits
of this change.
Differential Revision: https://reviews.llvm.org/D62787
llvm-svn: 362629
Any symbols defined in the LTO object are by definition the ones we
want in the final output so we skip the comdat group checking in those
cases.
This change makes the ELF code more explicit about this and means
that wasm and ELF do this in the same way.
Differential Revision: https://reviews.llvm.org/D62884
llvm-svn: 362625
Summary:
In DistributionExample.cmake be sure we use a LTO
capable linker, the easiest to choose is lld.
Reviewers: beanz
Reviewed By: beanz
Patch By: winksaville
Subscribers: mgorny, mehdi_amini, inglorion, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62279
llvm-svn: 362624
When running dsymutil on a fat binary, we use temporary files in a small
vector of size four. When processing more than 4 architectures, this
resulted in a user-after-move, because the temporary files got moved to
the heap. Instead of storing an optional temp file, we now use a unique
pointer, so the location of the actual temp file doesn't change.
We could test this by checking in 5 binaries for 5 different
architectures, but this seems wasteful, especially since the number of
elements in the small vector is arbitrary.
llvm-svn: 362621
As suggested in D62498 - collectConcatOps() matches both
concat_vectors and insert_subvector patterns, and we see
more test improvements by using the more general match.
llvm-svn: 362620
Summary:
Once we've attached to the process we load all current modules and also set a breakpoint at the rendezvous break address.
However, we don't do this if we already have a load address for the image info address (e.g.: DT_DEBUG on ELF). This code was added 4 years ago when adding support for `$qXfer:Libraries:` packet (https://reviews.llvm.org/D9471) but its intention is not 100% clear to me. It seems to me we're using that check to know if the modules have already been loaded (which they have if `$qXfer:Libraries:` is supported by the gdb server) and skip loading the modules again in the following `if` block. The problem is that we also skip setting the Rendezvous breakpoint so we stop knowing when the process loads new modules.
I fix this by moving the call to set the breakpoint to the end of the function so we always call it as long as we have a valid executable.
Reviewers: ADodds, clayborg, eugene, labath
Reviewed By: eugene, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62168
llvm-svn: 362619
This patch fixes a regression caused by the operand reordering refactoring patch https://reviews.llvm.org/D59973 .
The fix changes the strategy to Splat instead of Opcode, if broadcast opportunities are found.
Please see the lit test for some examples.
Committed on behalf of @vporpo (Vasileios Porpodas)
Differential Revision: https://reviews.llvm.org/D62427
llvm-svn: 362613
Instead of passing around fast-math-flags as a parameter, we can set those
using an IRBuilder guard object. This is no-functional-change-intended.
The motivation is to eventually fix the vectorizers to use and set the
correct fast-math-flags for reductions. Examples of that not behaving as
expected are:
https://bugs.llvm.org/show_bug.cgi?id=23116 (should be able to reduce with less than 'fast')
https://bugs.llvm.org/show_bug.cgi?id=35538 (possible miscompile for -0.0)
D61802 (should be able to reduce with IR-level FMF)
Differential Revision: https://reviews.llvm.org/D62272
llvm-svn: 362612
As reported in https://bugs.llvm.org/show_bug.cgi?id=42113, there are a
number of locations in Clang where it is assumed that exception
specifications are only valid in C++ mode. Since the original
justification for the NoThrow Exception Specifier Type was C++ related,
this patch just makes C mode use the attribute-based nothrow handling.
Additionally, I noticed that the handling of non-prototype functions
regressed the behavior of the nothrow attribute, in part because it is
was listed in the function type macro(which I did in the previous
patch). In reality, it should only be doing so in a conditional nature,
so this patch removes it there and puts it directly in the switch to be
handled correctly.
llvm-svn: 362607
References to arbitrary address spaces can't always be bound to
temporaries. This change extends the reference binding logic to
check that the address space of a temporary can be implicitly
converted to the address space in a reference when temporary
materialization is performed.
Differential Revision: https://reviews.llvm.org/D61318
llvm-svn: 362604
We have a few sections that can be added implicitly to the output:
".dynsym", ".dynstr", ".symtab", ".strtab" and ".shstrtab".
Problem appears when such section is listed explicitly in YAML.
In that case it's content is written twice:
first time during writing of regular sections listed in the document
and second time during special handling.
Because of that their file offsets can become unexpectedly broken:
(yaml file for sample below lists .dynsym explicitly before .text.foo)
Before patch:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .dynsym DYNSYM 0000000000000100 00000250
0000000000000030 0000000000000018 A 6 0 8
[ 2] .text.foo PROGBITS 0000000000000200 00000200
0000000000000000 0000000000000000 AX 0 0 0
After patch:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .dynsym DYNSYM 0000000000000100 00000200
0000000000000030 0000000000000018 A 6 0 8
[ 2] .text.foo PROGBITS 0000000000000200 00000230
0000000000000000 0000000000000000 AX 0 0 0
This patch reorganizes our code and fixes the issue described.
Differential revision: https://reviews.llvm.org/D62809
llvm-svn: 362602
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
This is the LLVM part of this change, the Clang part contains the full
description in its commit message.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362600
We already handle the case where we combine shuffle(extractsubvector(x),extractsubvector(x)), this relaxes the requirement to permit different sources as long as they have the same value type.
This causes a couple of cases where the VPERMV3 binary shuffles occur at a wider width than before, which I intend to improve in future commits - but as only the subvector's mask indices are defined, these will broadcast so we don't see any increase in constant size.
llvm-svn: 362599
Akira Hatanaka