| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
We have to delete the block manually or it leaks. That triggers failures in
-fsanitize=leak bots (unsurprisingly), which should be fixed by this patch.
llvm-svn: 293347
|
| |
|
|
|
|
|
|
| |
This reverts r293337, which breaks tests on Windows:
malloc-no-intercept-499eb7.o : error LNK2019: unresolved external symbol _mallinfo referenced in function _main
llvm-svn: 293346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inf-loop (PR31751)
This is a minimal patch to avoid the infinite loop in:
https://llvm.org/bugs/show_bug.cgi?id=31751
But the general problem is bigger: we're not canonicalizing all of the min/max forms reported
by value tracking's matchSelectPattern(), and we don't define min/max consistently. Some code
uses matchSelectPattern(), other code uses matchers like m_Umax, and others have their own
inline definitions which may be subtly different from any of the above.
The reason that the test cases in this patch need a cast op to trigger is because we don't
(yet) canonicalize all min/max forms based on matchSelectPattern() in
canonicalizeMinMaxWithConstant(), but we do make min/max+cast transforms based on
matchSelectPattern() in visitSelectInst().
The location of the icmp transforms that trigger the inf-loop seems arbitrary at best, so
I'm moving those behind the min/max fence in visitICmpInst() as the quick fix.
llvm-svn: 293345
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DiscardableODR/linkonce_odr
As Mehdi put it, entities should either be
available_externally+weak_odr, or linkonce_odr+linkonce_odr. While some
functions are emitted a_e/weak, their local variables were emitted
a_e/linkonce_odr.
While it might be nice to emit them a_e/weak, the Itanium ABI (& best
guess at MSVC's behavior as well) requires the local to be
linkonce/linkonce.
Reviewers: rsmith, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29233
llvm-svn: 293344
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ubsan does not report UB shifts in some cases where the shift exponent
needs to be truncated to match the type of the shift base. We perform a
range check on the truncated shift amount, leading to false negatives.
Fix the issue (PR27271) by performing the range check on the original
shift amount.
Differential Revision: https://reviews.llvm.org/D29234
llvm-svn: 293343
|
| |
|
|
|
|
| |
TypeMetadataUtils.cpp. NFC.
llvm-svn: 293341
|
| |
|
|
|
|
|
|
|
| |
Add some generally useful isl tools into a their own new ISLTools.cpp.
These are the helpers were extracted from and will be use by the DeLICM
algorithm (https://reviews.llvm.org/D24716).
Suggested-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 293340
|
| |
|
|
| |
llvm-svn: 293339
|
| |
|
|
|
|
|
|
|
|
| |
coverage/smoke Gfx7/8 testing.
Coverage/smoke Gfx7/8 tests were committed r292922 but then reverted
by r292974 due to AddressSanitizer failure, which is fixed by this patch.
Tests to be re-committed soon.
llvm-svn: 293338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In https://bugs.freebsd.org/215125 I was notified that some configure
scripts attempt to test for the Linux-specific `mallinfo` and `mallopt`
functions by compiling and linking small programs which references the
functions, and observing whether that results in errors.
FreeBSD and macOS do not have the `mallinfo` and `mallopt` functions, so
normally these tests would fail, but when sanitizers are enabled, they
incorrectly succeed, because the sanitizers define interceptors for
these functions. This also applies to some other malloc-related
functions, such as `memalign`, `pvalloc` and `cfree`.
Fix this by not intercepting `mallinfo`, `mallopt`, `memalign`,
`pvalloc` and `cfree` for FreeBSD and macOS, in all sanitizers.
Reviewers: emaste, kcc
Subscribers: hans, joerg, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D27654
llvm-svn: 293337
|
| |
|
|
|
|
|
| |
Mostly this just fixes bad wrapping caused by the reformat, with tiny
changes sprinkled here and there.
llvm-svn: 293336
|
| |
|
|
|
|
|
| |
Since it's not actually a generic MI, its register operands need a RegClass,
which is conveniently the target's pointer RegClass.
llvm-svn: 293335
|
| |
|
|
|
|
| |
Should fix machine verifier failures.
llvm-svn: 293334
|
| |
|
|
|
|
| |
Fixes an assertion failure on PS4 targets.
llvm-svn: 293333
|
| |
|
|
| |
llvm-svn: 293331
|
| |
|
|
|
|
| |
Found with ASAN + libFuzzer by Kostya Serebryany <kcc@google.com>
llvm-svn: 293330
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change the original algorithm so that it scales better when meeting
very large bitcode where every instruction does not implies a global.
The target query is "how to you get all the globals referenced by
another global"?
Before this patch, it was doing this by walking the body (or the
initializer) and collecting the references. What this patch is doing,
it precomputing the answer to this query for the whole module by
walking the use-list of every global instead.
Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>
Differential Revision: https://reviews.llvm.org/D28549
llvm-svn: 293328
|
| |
|
|
|
|
| |
passes.
llvm-svn: 293327
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29045
llvm-svn: 293325
|
| |
|
|
|
|
|
|
| |
Preparation for upcoming changes. No testcase as none of the public
targets bundles early enough and has a post machine scheduler enabled at
the same time. The error is also easily catched by asserts.
llvm-svn: 293324
|
| |
|
|
| |
llvm-svn: 293323
|
| |
|
|
|
|
| |
Comment, doxygen and a bit of whitespace cleanup.
llvm-svn: 293322
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, wdng, nhaehnle, yaxunl, llvm-commits, tony-tye
Differential Revision: https://reviews.llvm.org/D29068
llvm-svn: 293321
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ELF] Fixed formatting. NFC
and
[ELF] Bypass section type check
Differential revision: https://reviews.llvm.org/D28761
They do the opposite of what was asked for in the code review.
llvm-svn: 293320
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29224
llvm-svn: 293318
|
| |
|
|
|
|
|
|
|
| |
Put the duplicated i_maxmin into traits_t by adding new members max_value and
min_value. Put ___kmp_size_type into traits_t by adding member type_size.
Differential Revision: https://reviews.llvm.org/D28847
llvm-svn: 293316
|
| |
|
|
|
|
|
|
| |
Patch by Vishakha Agrawal
Differential Revision: https://reviews.llvm.org/D28873
llvm-svn: 293315
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Small change to get the FREEP instruction to decode properly.
Reviewers: craig.topper
Reviewed By: craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29193
llvm-svn: 293314
|
| |
|
|
| |
llvm-svn: 293313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the monitor thread is used, most threads in the team directly go to
sleep if the copy of bt_intervals/bt_set is not available in the cache,
and this happens at least once per thread in the wait function, making the
overall performance slightly better.
This change tries to mimic this behavior by using the bt_intervals cache,
which simply keeps the blocktime interval in terms of the platform-dependent
ticks or nanoseconds.
Patch by Hansang Bae
Differential Revision: https://reviews.llvm.org/D28906
llvm-svn: 293312
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In r279546 I disabled all frame pointer elimination at the front-end on
ARM-Darwin (and warned about it) because before that the backend had been
silently ignoring these options. It turns out we didn't ignore
-momit-leaf-frame-pointer though, just the more general -fomit-frame-pointer.
So this re-enables passing that down to CodeGen so that everything really does
continue working as before (with better diagnostics).
llvm-svn: 293311
|
| |
|
|
|
|
|
|
|
|
|
| |
Accomplishes what r292982 was supposed to, which ended up
only really making the necessary test changes.
This should be applied to the 4.0 branch.
Patch by Vedran Miletić <vedran@miletic.net>
llvm-svn: 293310
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interleaved access pass is an IR-to-IR transformation that runs before code
generation. It matches interleaved memory operations to target-specific
intrinsics (that are later lowered to load and store multiple instructions on
ARM/AArch64). We place tests for similar passes (e.g., GlobalMergePass) under
test/Transforms. This patch moves the InterleavedAccessPass tests out of
test/CodeGen and into target-specific directories under
test/Transforms/InterleavedAccess.
Although the pass is an IR pass, many of the existing tests were llc tests
rather opt tests. For example, the tests would check for ldN/stN instructions
generated by llc rather than the intrinsic calls the pass actually inserts.
Thus, this patch updates all tests to be opt tests that check for the inserted
intrinsics. We already have separate CodeGen tests that ensure we lower the
interleaved access intrinsics to their corresponding ldN/stN instructions. In
addition to migrating the tests to opt, this patch also performs some minor
clean-up (to ensure consistent naming, etc.).
Differential Revision: https://reviews.llvm.org/D29184
llvm-svn: 293309
|
| |
|
|
| |
llvm-svn: 293308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change prevent the signed value of cost from being negative as the value is passed as an unsigned argument.
Reviewers: mcrosier, jmolloy, qcolombet, javed.absar
Reviewed By: mcrosier, qcolombet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28871
llvm-svn: 293307
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Both on Mac and Windows, it's common to have a 'Users' directory in the
root of the filesystem, so one might specify a filename as
'/Users/me/myfile.c'. clang-cl (as well as MSVC's cl.exe) will interpret
that as invoking the '/U' option, which is probably not what the user
wanted. Add a warning about this.
Differential Revision: https://reviews.llvm.org/D29198
llvm-svn: 293305
|
| |
|
|
| |
llvm-svn: 293304
|
| |
|
|
|
|
|
|
|
| |
With the adjustPassManager interface that is now possible to use
custom early module passes.
Differential Revision: https://reviews.llvm.org/D29189
llvm-svn: 293300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is fixing pr31761: BasicAA is deducing NoAlias
on the result of the GEP if the base pointer is itself NoAlias.
This is possible only if the NoAlias on the base pointer is
deduced with a non-sized query: this should guarantee that
the pointers are belonging to different memory allocation
and that the GEP can't legally jump from one to another.
Differential Revision: https://reviews.llvm.org/D29216
llvm-svn: 293293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MetadataLoader::MetadataLoaderImpl::parseOneMetadata.
Summary:
MetadataLoader::MetadataLoaderImpl::parseOneMetadata uses
the following construct in a number of places:
```
MetadataList.assignValue(<...>, NextMetadataNo++);
```
There, NextMetadataNo gets incremented, and since the order
of arguments evaluation is not specified, that can happen
before or after other arguments are evaluated.
In a few cases the other arguments indirectly use NextMetadataNo.
For instance, it's
```
MetadataList.assignValue(
GET_OR_DISTINCT(DIModule,
(Context, getMDOrNull(Record[1]),
getMDString(Record[2]), getMDString(Record[3]),
getMDString(Record[4]), getMDString(Record[5]))),
NextMetadataNo++);
```
getMDOrNull calls getMD that uses NextMetadataNo:
```
MetadataList.getMetadataFwdRef(NextMetadataNo);
```
Therefore, the order of evaluation becomes important. That caused
a very subtle LLD crash that only happens if compiled with GCC or
if LLD is built with LTO. In the case if LLD is compiled with Clang
and regular linking mode, everything worked as intended.
This change extracts incrementing of NextMetadataNo outside of
the arguments list to guarantee the correct order of evaluation.
For the record, this has taken 3 days to track to the origin. It all
started with a ThinLTO bot in Chrome not being able to link a target
if debug info is enabled.
Reviewers: pcc, mehdi_amini
Reviewed By: mehdi_amini
Subscribers: aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D29204
llvm-svn: 293291
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.
The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.
llvm-svn: 293290
|
| |
|
|
|
|
|
| |
Tamas pointed out that the macro name I used in r293282 was too vague.
Rename it to better reflect what it is used for.
llvm-svn: 293287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modify ObjC blocks impl wrt address spaces as follows:
- keep default private address space for blocks generated
as local variables (with captures);
- add global address space for global block literals (no captures);
- make the block invoke function and enqueue_kernel prototype with
the generic AS block pointer parameter to accommodate both
private and global AS cases from above;
- add block handling into default AS because it's implemented as
a special pointer type (BlockPointer) in the frontend and therefore
it is used as a pointer everywhere. This is also needed to accommodate
both private and global AS blocks for the two cases above.
- removes ObjC RT specific symbols (NSConcreteStackBlock and
NSConcreteGlobalBlock) in the OpenCL mode.
Review: https://reviews.llvm.org/D28814
llvm-svn: 293286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch teaches the Clang driver how to handle the N64 static
relocation model properly. It enforces the correct target feature
(+noabicalls) when -fno-pic is used. This is required as non-pic
N64 code as the abi extension to call PIC code (CPIC) is unsupported.
Make PIC the default for mips64 and mips64el, this affects both N32
& N64 ABIs, to better match GCC.
As part of this effort, clean up the assembler invocation command
builder, so the correct flags are used.
This and r293279 in LLVM resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
Reviewers: slthakur, seanbruno
Differential Revision: https://reviews.llvm.org/D29031
llvm-svn: 293285
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
llvm-svn: 293283
|
| |
|
|
|
|
|
|
|
| |
I foolishly thought I could simplify the condition to cover all android
targets. I was wrong - i386 headers don't define __NR_accept.
Revert back to enabling the workaround on arm an mips only.
llvm-svn: 293282
|
| |
|
|
|
|
|
|
| |
This moves the accept hack from the android toolchain file into
LLDBConfig.cmake. This allows successful lldb android compilation
without relying on our custom toolchain file.
llvm-svn: 293281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function call can appear in the arguments of another function call, eg.:
foo(bar());
This patch adds support for such cases.
Patch by Ivan Sidorenko!
Differential revision: https://reviews.llvm.org/D28905
llvm-svn: 293280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes one change to GOT handling and two changes to N64's
relocation model handling. Furthermore, the jumptable encodings have
been corrected for static N64.
Big GOT handling is now done via a new SDNode MipsGotHi - this node is
unconditionally lowered to an lui instruction.
The first change to N64's relocation handling is the lifting of the
restriction that N64 always uses PIC. Now it is possible to target static
environments.
The second change adds support for 64 bit symbols and enables them by
default. Previously N64 had patterns for sym32 mode only. In this mode all
symbols are assumed to have 32 bit addresses. sym32 mode support
is selectable with attribute 'sym32'. A follow on patch for clang will
add the necessary frontend parameter.
This partially resolves PR/23485.
Thanks to Brooks Davis for reporting the issue!
This version corrects a "Conditional jump or move depends on uninitialised
value(s)" error detected by valgrind present in the original commit.
Reviewers: dsanders, seanbruno, zoran.jovanovic, vkalintiris
Differential Revision: https://reviews.llvm.org/D23652
llvm-svn: 293279
|
| |
|
|
| |
llvm-svn: 293278
|