| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 244048
|
|
|
|
|
|
|
| |
Summary: Among other things, this allows -print-after-all/-print-before-all to
dump IR around this pass.
llvm-svn: 244046
|
|
|
|
| |
llvm-svn: 244045
|
|
|
|
| |
llvm-svn: 244044
|
|
|
|
| |
llvm-svn: 244043
|
|
|
|
|
|
|
|
|
| |
Summary: Among other things, this allows -print-after-all/-print-before-all to
dump IR around this pass.
This is the AArch64 version of r243052.
llvm-svn: 244041
|
|
|
|
| |
llvm-svn: 244038
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
return StringSwitch<int>(Flags)
.Case("g", 0x1)
.Case("nzcvq", 0x2)
.Case("nzcvqg", 0x3)
.Default(-1);
...
// The _g and _nzcvqg versions are only valid if the DSP extension is
// available.
if (!Subtarget->hasThumb2DSP() && (Mask & 0x2))
return -1;
ARMARM confirms that the comment is right, and the code was wrong.
llvm-svn: 244029
|
|
|
|
| |
llvm-svn: 244021
|
|
|
|
|
|
|
|
|
| |
In r242277, I updated the MachineCombiner to work with itineraries, but I
missed a call that is scheduling-model-only (the opcode-only form of
computeInstrLatency). Using the form that takes an MI* allows this to work with
itineraries (and should be NFC for subtargets with scheduling models).
llvm-svn: 244020
|
|
|
|
| |
llvm-svn: 244016
|
|
|
|
| |
llvm-svn: 243999
|
|
|
|
|
|
|
|
|
|
|
| |
As documented in the LLVM Coding Standards, indeed MSVC incorrectly asserts
on this in Debug mode. This happens when building clang with Visual C++ and
-triple i686-pc-windows-gnu on these clang regression tests:
clang/test/CodeGen/2011-03-08-ZeroFieldUnionInitializer.c
clang/test/CodeGen/empty-union-init.c
llvm-svn: 243996
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create wrapper methods in the Function class for the OptimizeForSize and MinSize
attributes. We want to hide the logic of "or'ing" them together when optimizing
just for size (-Os).
Currently, we are not consistent about this and rely on a front-end to always set
OptimizeForSize (-Os) if MinSize (-Oz) is on. Thus, there are 18 FIXME changes here
that should be added as follow-on patches with regression tests.
This patch is NFC-intended: it just replaces existing direct accesses of the attributes
by the equivalent wrapper call.
Differential Revision: http://reviews.llvm.org/D11734
llvm-svn: 243994
|
|
|
|
|
|
|
|
|
| |
Begin adapting some of the implemented PPC64 relocations for PPC32 (with a
test case).
Patch by Pierre-Andre Saulais!
llvm-svn: 243991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the commentary for D11660, I wasn't sure if it was alright to create new
integer machine instructions without also creating the implicit EFLAGS operand.
From what I can see, the implicit operand is always created by the MachineInstrBuilder
based on the instruction type, so we don't have to do that explicitly. However, in
reviewing the debug output, I noticed that the operand was not marked as 'dead'.
The machine combiner should do that to preserve future optimization opportunities
that may be checking for that dead EFLAGS operand themselves.
Differential Revision: http://reviews.llvm.org/D11696
llvm-svn: 243990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FastISel.
Summary:
Previously, we would check whether the target is supported or not, only in
fastSelectInstruction(). This means that 64-bit targets could use FastISel too.
We fix this by checking every overridden method of the FastISel class and
by falling back to SelectionDAG if the target isn't supported. This change
should have been committed along with r243638, but somehow I missed it.
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11755
llvm-svn: 243986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
binary bitwise instructions.
It introduced two regressions on 64-bit big-endian targets running under N32
(MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4, and
MultiSource/Applications/kimwitu++/kc) The issue is that on 64-bit targets
comparisons such as BEQ compare the whole GPR64 but incorrectly tell the
instruction selector that they operate on GPR32's. This leads to the
elimination of i32->i64 extensions that are actually required by
comparisons to work correctly.
There's currently a patch under review that fixes this problem.
llvm-svn: 243984
|
|
|
|
| |
llvm-svn: 243977
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r243883 and r243961 made a use-after-free far more likely:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/6041/steps/check-llvm%20asan/logs/stdio
Unresolved nodes get inserted into the `Cycles` array. If they later
get resolved through RAUW, we need to update the reference. It's
interesting that this never hit before (maybe an asan-ified clang
bootstrap with `-flto -g` would have hit it, but I admit I haven't tried
anything quite that crazy).
llvm-svn: 243976
|
|
|
|
|
|
|
|
| |
This change was done as an audit and is by inspection. The new EH
system is still very much a work in progress. NFC for the landingpad
case.
llvm-svn: 243965
|
|
|
|
|
|
|
|
| |
function. NFCI.
This will make some upcoming bugfixes + improvements easier to manage.
llvm-svn: 243962
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r243883 started moving 'distinct' nodes instead of duplicated them in
lib/Linker. This had the side-effect of sometimes not cloning uniqued
nodes that reference them. I missed a corner case:
!named = !{!0}
!0 = !{!1}
!1 = distinct !{!0}
!0 is the entry point for "remapping", and a temporary clone (say,
!0-temp) is created and mapped in case we need to model a uniquing
cycle.
Recursive descent into !1. !1 is distinct, so we leave it alone,
but update its operand to !0-temp.
Pop back out to !0. Its only operand, !1, hasn't changed, so we don't
need to use !0-temp. !0-temp goes out of scope, and we're finished
remapping, but we're left with:
!named = !{!0}
!0 = !{!1}
!1 = distinct !{null} ; uh oh...
Previously, if !0 and !0-temp ended up with identical operands, then
!0-temp couldn't have been referenced at all. Now that distinct nodes
don't get duplicated, that assumption is invalid. We need to
!0-temp->replaceAllUsesWith(!0) before freeing !0-temp.
I found this while running an internal `-flto -g` bootstrap. Strangely,
there was no case of this in the open source bootstrap I'd done before
commit...
llvm-svn: 243961
|
|
|
|
|
|
|
|
|
|
| |
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
llvm-svn: 243957
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the code path in ExpandUnalignedLoad which expands an unaligned vector/fp
value in terms of a legal integer load of the same size, the ChainResult needs
to be the chain result of the integer load.
No in-tree test case is currently available.
Patch by Jan Hranac!
llvm-svn: 243956
|
|
|
|
|
|
|
| |
This variant of addRuntimeCheck is only used now from the LoopVectorizer
which does not use this parameter.
llvm-svn: 243955
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds enum value for an existing metadata type -- make.implicit. Using preassigned enum will be helpful to get compile time type checking and avoid string construction and comparison. The patch also changes uses of make.implicit from string metadata to enum metadata. There is no functionality change.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11698
llvm-svn: 243954
|
|
|
|
|
|
|
|
|
| |
This adds the software division routines for the Windows RTABI. These are not
expected to be used often though as most modern Windows ARM capable targets
support hardware division. In the case that the target CPU doesnt support
hardware division, this will be the fallback.
llvm-svn: 243952
|
|
|
|
|
|
|
| |
Make the libcall updating table driven similar to the approach that the Linux
and Windows codepath does below. NFC.
llvm-svn: 243951
|
|
|
|
|
|
|
|
|
|
|
| |
contained types into the space when we have no contained types. This
fixes the UB stemming from a call to memcpy with a null pointer. This
also reduces the calls to allocate because this actually happens in
a notable client - Clang.
Found by UBSan.
llvm-svn: 243944
|
|
|
|
|
|
| |
This reverts commit r243348 and r243357. They caused PR24347.
llvm-svn: 243939
|
|
|
|
|
|
|
|
| |
Some are named "FP", others "SD", others still "FP*SD".
Rename all this to just use "FP", which, except for conversions
(which don't use this format naming scheme), implies "SD" anyway.
llvm-svn: 243936
|
|
|
|
| |
llvm-svn: 243935
|
|
|
|
|
|
|
|
| |
this is the last of them in my build of LLVM. Haven't tried Clang yet.
Found via UBSan.
llvm-svn: 243934
|
|
|
|
|
|
|
| |
It's already in SysRegMappings, no need to also have it in MSRMappings:
the latter is only used if we didn't find a match in the former.
llvm-svn: 243933
|
|
|
|
| |
llvm-svn: 243931
|
|
|
|
| |
llvm-svn: 243930
|
|
|
|
|
|
|
|
|
|
|
| |
There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and
is actually already vector-aware; let's use it instead of scalarizing!
The only interesting change is that for v2f32, we previously always used
use v4i32 as the integer vector type.
Use v2i32 instead, and mark FCOPYSIGN as Custom.
llvm-svn: 243926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to legalize it like it's any other binary operations. It's not,
because it accepts mismatched operand types. Because of that, we used
to hit various asserts and miscompiles.
Specialize vector legalizations to, in the worst case, unroll, or, when
possible, to just legalize the operand that needs legalization.
Scalarization isn't covered, because I can't think of a target where
some but not all of the 1-element vector types are to be scalarized.
llvm-svn: 243924
|
|
|
|
| |
llvm-svn: 243923
|
|
|
|
| |
llvm-svn: 243921
|
|
|
|
|
|
|
|
| |
The previous commits moved this functionality into the client.
Also remove the now unused member variable.
llvm-svn: 243920
|
|
|
|
|
| |
Reviewers: Duncan P. N. Exon Smith
llvm-svn: 243915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deprecated in C++11
Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).
Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.
Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.
llvm-svn: 243909
|
|
|
|
| |
llvm-svn: 243907
|
|
|
|
| |
llvm-svn: 243903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
through PHI nodes across iterations.
This patch teaches the new advanced loop unrolling heuristics to propagate
constants into the loop from the preheader and around the backedge after
simulating each iteration. This lets us brute force solve simple recurrances
that aren't modeled effectively by SCEV. It also makes it more clear why we
need to process the loop in-order rather than bottom-up which might otherwise
make much more sense (for example, for DCE).
This came out of an attempt I'm making to develop a principled way to account
for dead code in the unroll estimation. When I implemented
a forward-propagating version of that it produced incorrect results due to
failing to propagate *cost* between loop iterations through the PHI nodes, and
it occured to me we really should at least propagate simplifications across
those edges, and it is quite easy thanks to the loop being in canonical and
LCSSA form.
Differential Revision: http://reviews.llvm.org/D11706
llvm-svn: 243900
|
|
|
|
| |
llvm-svn: 243899
|
|
|
|
|
|
|
|
|
|
| |
deprecated in C++11
Some functions return concrete ByteStreamers by value - explicitly
support that in the base class. (dtor can be virtual, no one seems to be
polymorphically owning/destroying them)
llvm-svn: 243897
|
|
|
|
|
|
|
|
|
|
|
|
| |
in ways that are deprecated in C++11
This reverts commit r243888, recommitting r243824.
This broke the Windows build due to a difference in the C++ standard
library implementation. Using emplace/forward_as_tuple should ensure
there's no need to copy ValIDs.
llvm-svn: 243896
|