| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Python on Windows raises this OverflowError:
gotit = waiter.acquire(True, timeout)
OverflowError: timestamp too large to convert to C _PyTime_t
So it seems this API behave the same way on every OS.
Also reverts the dependent commit a660dc590a5e8dafa1ba6ed56447ede151d17bd9.
llvm-svn: 375143
|
|
|
|
| |
llvm-svn: 375142
|
|
|
|
|
|
| |
In the process of writing D69009, I realized we have two distinct sets of invariants within this single function, and basically no shared logic. The optimize loop exit transforms (including the new one in D69009) only care about *analyzeable* exits. Loop predication, on the other hand, has to reason about *all* exits. At the moment, we have the property (due to the requirement for an exact btc) that all exits are analyzeable, but that will likely change in the future as we add widenable condition support.
llvm-svn: 375138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the long run we should come up with another mechanism for marking
call instructions as heap allocation sites, and remove this workaround.
For now, we've had two bug reports about this, so let's apply this
workaround. SLH (the other client of instruction labels) probably has
the same bug, but the solution there is more likely to be to mark the
call instruction as not duplicatable, which doesn't work for debug info.
Reviewers: akhuang
Subscribers: aprantl, hiraditya, aganea, chandlerc, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69068
llvm-svn: 375137
|
|
|
|
|
|
| |
This reverts r375132 (git commit 00bbe990c5d4472d5413479a539b3d6edbb3ca7a)
llvm-svn: 375136
|
|
|
|
|
|
|
|
| |
shift-of-trunc" (PR42563)
https://bugs.llvm.org/show_bug.cgi?id=42563
llvm-svn: 375135
|
|
|
|
|
|
|
|
| |
If we can determined, that the global tid parameter can be used in the
function, better to use it rather than calling __kmpc_global_thread_num
function.
llvm-svn: 375134
|
|
|
|
| |
llvm-svn: 375133
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This has been tested with gcc trunk on openSUSE Tumbleweed on the HiFive Unleashed.
Patch by Andreas Schwab (schwab)
Reviewers: luismarques
Reviewed By: luismarques
Subscribers: mhorne, emaste, luismarques, asb, mgorny, fedor.sergeev, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, lenary, s.egerton, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D66870
llvm-svn: 375132
|
|
|
|
|
|
|
|
| |
This updates some more places using `%T` to use `%/T` for path normalization.
If this does not work, this and r375126 should be reverted together.
llvm-svn: 375131
|
|
|
|
| |
llvm-svn: 375130
|
|
|
|
|
|
|
|
| |
We always want to use a deadline when calling `result.await`. Let's
synthesize an artificial deadline (positive infinity) to simplify code
and do less busy waiting.
llvm-svn: 375129
|
|
|
|
|
|
|
| |
The hope is that with a little OO we can nicely factor out the
differences.
llvm-svn: 375128
|
|
|
|
| |
llvm-svn: 375127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Glob support was improved to accept `\` as an escape character in r375051, but reverted as r375052 due to a failure in this test on Windows.
The reason this failure seems Windows specific is because the path separator `\` is currently being relied on to be interpreted literally instead of as an escape character. Per documentation on linker input section wildcard patterns, this seems to be a bug in lld accepting `\` as a literal instead of an escape character.
For example:
```
SECTIONS{ .foo :{ /path/to/foo.o(.foo) }} # OK: standard UNIX path
SECTIONS{ .foo :{ C:/path/to/foo.o(.foo) }} # OK: windows accepts slashes in either direction
SECTIONS{ .foo :{ C:\\path\\to\\foo.o(.foo) }} # OK: escape character used to match a literal \
SECTIONS{ .foo :{ C:\path\to\foo.o(.foo) }} # BAD: this actually matches the path C:pathtofoo.o(.foo)
```
This avoids the problem in the test by using `%/T` in place of `%T` to normalize the path separator to `/`, which windows should also accept.
This patch just fixes the test, and glob support will be be relanded separately.
For a sample buildbot error, see: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11578/steps/stage%201%20check/logs/stdio
Reviewers: evgeny777, ruiu, MaskRay, espindola
Reviewed By: ruiu, MaskRay
Subscribers: emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69074
llvm-svn: 375126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointer types.
For example, in Objective-C mode, the initialization of 'x' in:
```
@implementation MyType
+ (void)someClassMethod {
MyType *x = self;
}
@end
```
is correctly diagnosed with an incompatible-pointer-types warning, but
in Objective-C++ mode, it is not diagnosed at all -- even though
incompatible pointer conversions generally become an error in C++.
This patch fixes that oversight, allowing implicit conversions
involving Class only to/from unqualified-id, and between qualified and
unqualified Class, where the protocols are compatible.
Note that this does change some behaviors in Objective-C, as well, as
shown by the modified tests.
Of particular note is that assignment from from 'Class<MyProtocol>' to
'id<MyProtocol>' now warns. (Despite appearances, those are not
compatible types. 'Class<MyProtocol>' is not expected to have instance
methods defined by 'MyProtocol', while 'id<MyProtocol>' is.)
Differential Revision: https://reviews.llvm.org/D67983
llvm-svn: 375125
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is especially important for Objective-C++, which is entirely
missing this testing at the moment.
This annotates with "FIXME" the cases which I change in the next
patch -- I primarily wanted to document the current state of things so
that the effect of the code change is made clear.
Differential Revision: https://reviews.llvm.org/D67982
llvm-svn: 375124
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55724
llvm-svn: 375123
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D55718
llvm-svn: 375122
|
|
|
|
|
|
| |
This series of patches still breaks a Windows bot.
llvm-svn: 375121
|
|
|
|
|
|
| |
This series of patches still breaks a Windows bot.
llvm-svn: 375120
|
|
|
|
|
|
|
|
|
| |
regions.
The real global thread id must be passed to the outlined region instead
of the zero thread id.
llvm-svn: 375119
|
|
|
|
|
|
|
|
|
|
| |
PR43145 revealed two places where Clang was attempting to create a
bitcast without considering the address space of class types during
C++ class code generation.
Differential Revision: https://reviews.llvm.org/D68403
llvm-svn: 375118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Move the RelationKind from Serialization.h to Relation.h. This patch doesn't
introduce any breaking changes.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68981
llvm-svn: 375117
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using lit's internal shell, RUN lines like the following
accidentally execute an external `diff` instead of lit's internal
`diff`:
```
# RUN: program | diff file -
```
Such cases exist now, in `clang/test/Analysis` for example. We are
preparing patches to ensure lit's internal `diff` is called in such
cases, which will then fail because lit's internal `diff` doesn't
recognize `-` as a command-line option. This patch adds support for
`-` to mean stdin.
Reviewed By: probinson, rnk
Differential Revision: https://reviews.llvm.org/D67643
llvm-svn: 375116
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using lit's internal shell, RUN lines like the following
accidentally execute an external `diff` instead of lit's internal
`diff`:
```
# RUN: program | diff file -
# RUN: not diff file1 file2 | FileCheck %s
```
Such cases exist now, in `clang/test/Analysis` for example. We are
preparing patches to ensure lit's internal `diff` is called in such
cases, which will then fail because lit's internal `diff` cannot
currently be used in pipelines and doesn't recognize `-` as a
command-line option.
To enable pipelines, this patch moves lit's `diff` implementation into
an out-of-process script, similar to lit's `cat` implementation. A
follow-up patch will implement `-` to mean stdin.
Reviewed By: probinson, stella.stamenova
Differential Revision: https://reviews.llvm.org/D66574
llvm-svn: 375114
|
|
|
|
|
|
|
|
|
| |
This patch provides support for peudo ops including ADDIStocHA8, ADDIStocHA, LWZtocL,
LDtoc, LDtocL for AIX, lowering them from MIR to assembly.
Differential Revision: https://reviews.llvm.org/D68341
llvm-svn: 375113
|
|
|
|
|
|
|
|
|
|
|
| |
The idea of this page is to document work in progress functionality
and also describe the plan of future development work.
Patch by Anastasia Stulova.
Differential Revision: https://reviews.llvm.org/D69072
llvm-svn: 375111
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D69021
llvm-svn: 375110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added estimation for zero size insertelement, extractelement
and llvm.fabs operators.
Updated inline/unroll parameters default values.
Reviewers: rampitec, arsenm
Reviewed By: arsenm
Subscribers: kzhuravl, jvesely, wdng, nhaehnle, yaxunl, dstuttard, tpr, t-tye, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68881
llvm-svn: 375109
|
|
|
|
|
|
|
|
|
|
| |
Allow us to generate truncating masked store which take v4i32 and
v8i16 vectors and can store to v4i8, v4i16 and v8i8 and memory.
Removed support for unaligned masked stores.
Differential Revision: https://reviews.llvm.org/D68461
llvm-svn: 375108
|
|
|
|
|
|
|
|
| |
docs-llvm-html fails => unknown option: O
There are lots of formatting issues in the file but they will be fixed by D68998.
llvm-svn: 375107
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since GNU ar 2.31, the 't' operation prints member offsets beside file
names if the 'O' modifier is specified. 'O' is ignored for thin
archives.
Reviewed By: gbreynoo, ruiu
Differential Revision: https://reviews.llvm.org/D69087
llvm-svn: 375106
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exposed by D69041. If SHT_SYMTAB does not exist, ELFObjcopy.cpp:handleArgs will crash due
to a null pointer dereference.
for (const NewSymbolInfo &SI : Config.ELF->SymbolsToAdd) {
...
Obj.SymbolTable->addSymbol(
Fix this by creating .symtab and .strtab on demand in ELFBuilder<ELFT>::readSections,
if --add-symbol is specified.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D69093
llvm-svn: 375105
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D68581
llvm-svn: 375104
|
|
|
|
|
|
|
|
| |
null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<> directly and if not assert will fire for us.
llvm-svn: 375103
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 375102
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 375101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR43687)
We can't normally stumble into that assertion because a tautological
*conditional* `br` in loop body is required, one that always
branches to loop latch. But that should have been always folded
to an unconditional branch before we get it.
But that is not guaranteed if the pass is run standalone.
So let's just promote the assertion into a proper check.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43687
llvm-svn: 375100
|
|
|
|
|
|
| |
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us.
llvm-svn: 375097
|
|
|
|
|
|
|
|
|
|
|
| |
The change was:
SHT_GNU_verdef { -> VersionDefinitions [
SHT_GNU_verneed { -> VersionRequirements [
Version symbols [ -> VersionSymbols [
EH_FRAME Header [ -> EHFrameHeader {
llvm-svn: 375096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our LLVM-style output was inconsistent.
This patch changes the output in the following way:
SHT_GNU_verdef { -> VersionDefinitions [
SHT_GNU_verneed { -> VersionRequirements [
Version symbols [ -> VersionSymbols [
EH_FRAME Header [ -> EHFrameHeader {
Differential revision: https://reviews.llvm.org/D68636
llvm-svn: 375095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove dead virtual functions from vtables with
replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up
correctly.
Original commit message:
Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.
This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.
To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.
The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.
This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.
To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.
I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.
On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.
I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.
I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).
Differential revision: https://reviews.llvm.org/D63932
llvm-svn: 375094
|
|
|
|
|
|
|
| |
Hopefully fixing the AlignmentDeathTest.AlignAddr failures (e.g. at
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/10925)
llvm-svn: 375090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR42699)
Summary:
Currently when computing a GEP offset using the function EmitGEPOffset
for the following instruction
getelementptr inbounds i32, i32* %p, i64 %offs
we get
mul nuw i64 %offs, 4
Unfortunately we cannot assume that unsigned wrapping won't happen
here because %offs is allowed to be negative.
Making such assumptions can lead to miscompilations: see the new test
test24_neg_offs in InstCombine/icmp.ll. Without the patch InstCombine
would generate the following comparison:
icmp eq i64 %offs, 4611686018427387902; 0x3ffffffffffffffe
Whereas the correct value to compare with is -2.
This patch replaces the NUW flag with NSW in the multiplication
instructions generated by EmitGEPOffset and adjusts the test suite.
https://bugs.llvm.org/show_bug.cgi?id=42699
Reviewers: chandlerc, craig.topper, ostannard, lebedev.ri, spatel, efriedma, nlopes, aqjune
Reviewed By: lebedev.ri
Subscribers: reames, lebedev.ri, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68342
llvm-svn: 375089
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the section index."
This broke llvm-objdump in 32-bit builds, see e.g.
http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/10925
> Summary:
> When listing the index in `llvm-objdump -h`, use a zero-based counter instead of the actual section index (e.g. shdr->sh_index for ELF).
>
> While this is effectively a noop for now (except one unit test for XCOFF), the index values will change in a future patch that filters certain sections out (e.g. symbol tables). See D68669 for more context. Note: the test case in `test/tools/llvm-objdump/X86/section-index.s` already covers the case of incrementing the section index counter when sections are skipped.
>
> Reviewers: grimar, jhenderson, espindola
>
> Reviewed By: grimar
>
> Subscribers: emaste, sbc100, arichardson, aheejin, arphaman, seiya, llvm-commits, MaskRay
>
> Tags: #llvm
>
> Differential Revision: https://reviews.llvm.org/D68848
llvm-svn: 375088
|
|
|
|
|
|
|
|
| |
Unlike VPT, VPST just uses the current value of VPR.P0.
Differential Revision: https://reviews.llvm.org/D69037
llvm-svn: 375087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a NFC change that removes the NFA->DFA construction and emission logic from DFAPacketizerEmitter and instead uses the generic DFAEmitter logic. This allows DFAPacketizer to use the Automaton class from Support and remove a bunch of logic there too.
After this patch, DFAPacketizer is mostly logic for grepping Itineraries and collecting functional units, with no state machine logic. This will allow us to modernize by removing the 16-functional-unit limit and supporting non-itinerary functional units. This is all for followup patches.
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68992
llvm-svn: 375086
|
|
|
|
|
|
|
|
|
|
|
| |
Add generic DAG combine for extending masked loads.
Allow us to generate sext/zext masked loads which can access v4i8,
v8i8 and v4i16 memory to produce v4i32, v8i16 and v4i32 respectively.
Differential Revision: https://reviews.llvm.org/D68337
llvm-svn: 375085
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68993
llvm-svn: 375084
|