| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
If ScalarEvolution cannot look through some expression but we do, it
might happen that a multiplication will arrive at the
SCEVAffinator::visitMulExpr. While we could always try to improve the
extractConstantFactor function we might still miss something, thus we
reintroduce the code to generate multiplicative piecewise-affine
functions as a fall-back.
llvm-svn: 265777
|
|
|
|
| |
llvm-svn: 265776
|
|
|
|
|
|
|
|
|
| |
The findValues() function did not look through div & srem instructions
that were part of the argument SCEV. However, in different other
places we already look through it. This mismatch caused us to preload
values in the wrong order.
llvm-svn: 265775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This check flags initializers of globals that access extern objects, and therefore can lead to order-of-initialization problems (this recommandation is part of CPP core guidelines).
Note that this only checks half of the guideline for now (it does not enforce using constexpr functions).
Reviewers: aaron.ballman, alexfh
Subscribers: aaron.ballman, etienneb, Eugene.Zelenko, cfe-commits
Patch by Clement Courbet!
Differential Revision: http://reviews.llvm.org/D18649
llvm-svn: 265774
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18820
llvm-svn: 265773
|
|
|
|
|
|
|
|
| |
instructions
Differential Revision: http://reviews.llvm.org/D16454
llvm-svn: 265772
|
|
|
|
| |
llvm-svn: 265771
|
|
|
|
|
|
|
| |
It seems that llc cannot be called used in assembler tests so test that
checks asm for particular target needs to be moved to codegen.
llvm-svn: 265770
|
|
|
|
|
|
| |
due to different filecheck prefix. NFC.
llvm-svn: 265769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r265765, reapplying r265759 after changing a call from
LocalAsMetadata::get to ValueAsMetadata::get (and adding a unit test). When a
local value is mapped to a constant (like "i32 %a" => "i32 7"), the new debug
intrinsic operand may no longer be pointing at a local.
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_build/19020/
The previous coommit message follows:
--
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265768
|
|
|
|
|
|
| |
Replace mayBeOverridden with isInterposable
llvm-svn: 265767
|
|
|
|
|
|
| |
preprocessed output.
llvm-svn: 265766
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r265759, since even this limited version breaks some
bots:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/3311
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/17696
This also reverts r265761 "ValueMapper: Unduplicate
RF_NoModuleLevelChanges check, NFC", since I had trouble separating it
from r265759.
llvm-svn: 265765
|
|
|
|
|
|
|
| |
Original commit message:
[TargetRegisterInfo] Refactor the code to use BitMaskClassIterator.
llvm-svn: 265764
|
|
|
|
|
|
|
| |
Make sure we do not read past the size of the mask. Although we were not using
the value read, this is bad and makes ASan complain.
llvm-svn: 265763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
|
|
|
|
| |
llvm-svn: 265761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch closes a gap in the DWARF backend that caused LLVM to drop
debug info for floating point variables that were constant for part of
their scope. Floating point constants are emitted as one or more
DW_OP_constu joined via DW_OP_piece.
This fixes a regression caught by the LLDB testsuite that I introduced
in r262247 when we stopped blindly expanding the range of singular
DBG_VALUEs to span the entire scope and started to emit location lists
with accurate ranges instead.
Also deletes a now-impossible testcase (debug-loc-empty-entries).
<rdar://problem/25448338>
llvm-svn: 265760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a partial re-commit -- maybe more of a re-implementation -- of
r265631 (reverted in r265637).
This makes RF_IgnoreMissingLocals behave (almost) consistently between
the Value and the Metadata hierarchy. In particular:
- MapValue returns nullptr or "metadata !{}" for missing locals in
MetadataAsValue/LocalAsMetadata bridging paris, depending on
the RF_IgnoreMissingLocals flag.
- MapValue doesn't memoize LocalAsMetadata-related results.
- MapMetadata no longer deals with LocalAsMetadata or
RF_IgnoreMissingLocals at all. (This wasn't in r265631 at all, but
I realized during testing it would make the patch simpler with no
loss of generality.)
r265631 went too far, making both functions universally ignore
RF_IgnoreMissingLocals. This broke building (e.g.) compiler-rt.
Reassociate (and possibly other passes) don't currently maintain
dominates-use invariants for metadata operands, resulting in IR like
this:
define void @foo(i32 %arg) {
call void @llvm.some.intrinsic(metadata i32 %x)
%x = add i32 1, i32 %arg
}
If the inliner chooses to inline @foo into another function, then
RemapInstruction will call `MapValue(metadata i32 %x)` and assert that
the return is not nullptr.
I've filed PR27273 to add a Verifier check and fix the underlying
problem in the optimization passes.
As a workaround, return `!{}` instead of nullptr for unmapped
LocalAsMetadata when RF_IgnoreMissingLocals is unset. Otherwise, match
the behaviour of r265631.
Original commit message:
ValueMapper: Make LocalAsMetadata match function-local Values
Start treating LocalAsMetadata similarly to function-local members of
the Value hierarchy in MapValue and MapMetadata.
- Don't memoize them.
- Return nullptr if they are missing.
This also cleans up ConstantAsMetadata to stop listening to the
RF_IgnoreMissingLocals flag.
llvm-svn: 265759
|
|
|
|
| |
llvm-svn: 265758
|
|
|
|
| |
llvm-svn: 265757
|
|
|
|
|
|
| |
support @import; use the form as written instead.
llvm-svn: 265756
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r265734.
Looks like ASan is not happy about it.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11741
Looking.
llvm-svn: 265755
|
|
|
|
|
|
|
| |
Print the mask of the partial mapping as an hexadecimal instead of a
binary value.
llvm-svn: 265754
|
|
|
|
|
|
|
|
| |
Patch by Douglas Yung!
Reviewed by Rafael Espindola
llvm-svn: 265753
|
|
|
|
|
|
|
| |
We need to check that if we reference a retainedType from
DICompileUnit we're actually referencing a DICompositeType.
llvm-svn: 265752
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See comments in patch; we were assuming that some stdlib math functions
would be defined in namespace std, when in fact the spec says they
should be defined in the global namespace. libstdc++4.9 became more
conforming and broke us.
This new implementation seems to cover the known knowns.
Reviewers: rsmith
Subscribers: cfe-commits, tra
Differential Revision: http://reviews.llvm.org/D18882
llvm-svn: 265751
|
|
|
|
| |
llvm-svn: 265750
|
|
|
|
| |
llvm-svn: 265749
|
|
|
|
| |
llvm-svn: 265748
|
|
|
|
|
|
| |
helper class.
llvm-svn: 265747
|
|
|
|
|
|
| |
class.
llvm-svn: 265746
|
|
|
|
|
|
|
|
| |
Properly print either the register class or the register bank or a
virtual register.
Get rid of a few ifdefs in the process.
llvm-svn: 265745
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18877
llvm-svn: 265744
|
|
|
|
|
|
| |
For GPR family we want the GPR register bank, not FPR!
llvm-svn: 265743
|
|
|
|
| |
llvm-svn: 265742
|
|
|
|
|
|
|
|
| |
Now, recordRegBankForType records only the first register bank that
covers a type instead of the last. This behavior can, nevertheless, be
override with the additional Force parameter to force the update.
llvm-svn: 265741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reference/pointer identity
TUs in each unit refer to the unit they are in, if the unit is moved
this reference is invalidated & things break.
No test case because UB isn't testable - ASan would likely catch this on
a large enough test case (just needs to have enough TUs that a
reallocation of the vector would occur) but didn't seem worthwhile. Up
for debate/revisiting if anyone feels strongly.
llvm-svn: 265740
|
|
|
|
|
|
|
| |
Teach the target independent code how to take advantage of type
information to get the mapping of an instruction.
llvm-svn: 265739
|
|
|
|
|
|
|
|
|
|
| |
are properly escaped in Python.
The Python import works by ensuring the directory of the module or package is in sys.path, and then it does a Python `import foo`. The original code was not escaping the backslashes in the directory path, so this wasn't working.
Differential Revision: http://reviews.llvm.org/D18873
llvm-svn: 265738
|
|
|
|
|
|
|
|
|
| |
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
|
|
|
|
|
|
|
|
|
|
|
|
| |
specific type.
This will be used to find the default mapping of the instruction.
Also, this information is recorded, instead of computed, because it is
expensive from a type to know which register bank maps it.
Indeed, we need to iterate through all the register classes of all the
register banks to find the one that maps the given type.
llvm-svn: 265736
|
|
|
|
|
|
|
|
|
|
|
| |
method.
NFC.
The refactoring intends to make the code more readable and expose
more features to potential derived classes.
llvm-svn: 265735
|
|
|
|
| |
llvm-svn: 265734
|
|
|
|
| |
llvm-svn: 265733
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
os to "ios" or "macosx" if it is unspecified. For environments
where there genuinely is no os, we don't want to errantly
convert that to ios/macosx, e.g. bare board debugging.
Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS. Same problem - these are not appropriate
platforms for bare board debugging environments.
Have Process::Attach's logging take place if either
process or target logging is enabled.
<rdar://problem/25592378>
llvm-svn: 265732
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265731
|
|
|
|
|
|
|
|
|
|
| |
iterate over register class bitmask.
Thanks to this helper class, it would not require for each user of the
register classes bitmask to actually know how they are represents.
Moreover, it will make the code much easier to read.
llvm-svn: 265730
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGen-level implementation. Instead of adding an attribute to clang's
FunctionDecl, add the IR attribute directly. This means a module built with
this flag is now compatible with code built without it and vice versa.
This change also results in the 'noalias' attribute no longer being added to
calls to operator new in the IR; it's now only added to the declaration. It
also fixes a bug where we failed to add the attribute to the 'nothrow' versions
(because we didn't implicitly declare them, there was no good time to inject a
fake attribute).
llvm-svn: 265728
|