| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
|  | 
The default implementation in BasicTTI already checks TLI and does
the right thing.
llvm-svn: 254993
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Currently, vectors of halfs end up as ConstantVectors, but there isn't
a good reason they can't be ConstantDataVectors. This should save some
memory.
llvm-svn: 254991
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
It's strange to duplicate the logic for emitting FP values into
emitGlobalConstantDataSequential, and it's even stranger that we end
up printing the verbose assembly comments differently between the two
paths. Just call into emitGlobalConstantFP rather than crudely
duplicating its logic.
llvm-svn: 254988
 | 
| | 
| 
| 
| 
| 
|  | 
rdar://9001553
llvm-svn: 254978
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Also add a stricter post-condition for IndVarSimplify.
Fixes PR25578.  Test case by Michael Zolotukhin.
Reviewers: hfinkel, atrick, mzolotukhin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15059
llvm-svn: 254977
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
(Note: the problematic invocation of hoistIVInc that caused PR24804 came
from IndVarSimplify, not from SCEVExpander itself)
Fixes PR24804.  Test case by David Majnemer.
Reviewers: hfinkel, majnemer, atrick, mzolotukhin
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15058
llvm-svn: 254976
 | 
| | 
| 
| 
| 
| 
|  | 
Will be used in a upcoming patch.
llvm-svn: 254975
 | 
| | 
| 
| 
|  | 
llvm-svn: 254968
 | 
| | 
| 
| 
|  | 
llvm-svn: 254967
 | 
| | 
| 
| 
|  | 
llvm-svn: 254960
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
254950 ended up being not NFC.  The previous code was overriding the flags for whether an instruction read or wrote memory using the target specific flags returned via TTI.  I'd missed this in my refactoring.  Since I mistakenly built only x86 and didn't notice the number of unsupported tests, I didn't catch that before the original checkin.
This raises an interesting issue though.  Given we have function attributes (i.e. readonly, readnone, argmemonly) which describe the aliasing of intrinsics, why does TTI have this information overriding the instruction definition at all?  I see no reason for this, but decided to preserve existing behavior for the moment.  The root issue might be that we don't have a "writeonly" attribute.
Original commit message:
[EarlyCSE] Simplify and invert ParseMemoryInst [NFCI]
Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.
The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.
Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.
llvm-svn: 254957
 | 
| | 
| 
| 
| 
| 
|  | 
It's causing test failures on AArch64.  Due to a bad build config on my part, I apparently wasn't running the tests I thought I was.
llvm-svn: 254954
 | 
| | 
| 
| 
|  | 
llvm-svn: 254952
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Restructure ParseMemoryInst - which was introduced to abstract over target specific load and stores instructions - to just query the underlying instructions. In theory, this could be slightly slower than caching the results, but in practice, it's very unlikely to be measurable.
The simple query scheme makes it far easier to understand, and much easier to extend with new queries. Given I'm about to need to add new query types, doing the cleanup first seemed worthwhile.
Do we still believe the target specific intrinsic handling is worthwhile in EarlyCSE? It adds quite a bit of complexity and makes the code harder to read. Being able to delete the abstraction entirely would be wonderful.
llvm-svn: 254950
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
When considering foo->bar inlining, if there is an indirect call in foo which gets resolved to a direct call (say baz), then we try to inline baz into bar with a threshold T and subtract max(T - Cost(bar->baz), 0) from Cost(foo->bar). This patch uses max(Threshold(bar->baz) - Cost(bar->baz)) instead, where Thresheld(bar->baz) could be different from T due to bonuses or subtractions. Threshold(bar->baz) - Cost(bar->baz) better represents the desirability of inlining baz into bar.
Differential Revision: http://reviews.llvm.org/D14309
llvm-svn: 254945
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Convert i1 values to i32 values if they should be allocated in GPRs instead of CRs.
Phabricator: http://reviews.llvm.org/D14064
llvm-svn: 254942
 | 
| | 
| 
| 
|  | 
llvm-svn: 254930
 | 
| | 
| 
| 
|  | 
llvm-svn: 254928
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
Add a field on the PassManagerBuilder that clang or gold can use to pass
down a pointer to the function index in memory to use for importing when
the ThinLTO backend is triggered. Add support to supply this to the
function import pass.
Reviewers: joker.eph, dexonsmith
Subscribers: davidxl, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D15024
llvm-svn: 254926
 | 
| | 
| 
| 
| 
| 
|  | 
attribute; NFCI
llvm-svn: 254925
 | 
| | 
| 
| 
| 
| 
| 
|  | 
We already linked available_externally and linkonce lazily, this just
adds declarations to the list.
llvm-svn: 254917
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
FP logic instructions are supported in DQ extension on AVX-512 target.
I use integer operations instead.
Added tests.
I also enabled FABS in this patch in order to check ANDPS.
The operations are FOR, FXOR, FAND, FANDN.
The instructions, that supported for 512-bit vector under DQ are:
VORPS/PD, VXORPS/PD, VANDPS/PD, FANDNPS/PD.
Differential Revision: http://reviews.llvm.org/D15110
llvm-svn: 254913
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
ARM ARM.
Summary: This reverts r254234, and adds a simple fix for the annoying case of use-after-free.
Reviewers: rengolin
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D15236
llvm-svn: 254912
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Patterns were missing for KNL target for <8 x i32>, <8 x float> masked load/store.
This intrinsic comes with all legal types:
<8 x float> @llvm.masked.load.v8f32(<8 x float>* %addr, i32 align, <8 x i1> %mask, <8 x float> %passThru),
but still requires lowering, because VMASKMOVPS, VMASKMOVDQU32 work with 512-bit vectors only.
All data operands should be widened to 512-bit vector.
The mask operand should be widened to v16i1 with zeroes.
Differential Revision: http://reviews.llvm.org/D15265
llvm-svn: 254909
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D14821
llvm-svn: 254908
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Now instead of changing it to the new format and then linking, it just
handles the old format while copying it over.
The main differences are:
* There is no rauw in the source module.
* An old format input is always upgraded.
The first item helps with having a sane API that passes in a GV list to
the linker.
The second one is a small step in deprecating the old format.
llvm-svn: 254907
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Adding support for FWORD type for MS inline asm.
Differential Revision: http://reviews.llvm.org/D15268
llvm-svn: 254904
 | 
| | 
| 
| 
| 
| 
|  | 
Additionally correct the Cortex-R7 definition to allow the FP16 feature.
llvm-svn: 254900
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D9824
llvm-svn: 254897
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
We are inserting both Scope and SP into the Seen map and check whether
it was already there in which case we skip the validation (the idea
being that we already checked this Subprogram before). However,
if (Scope == SP) as MDNodes, then inserting the Scope, will trigger
the Seen check causing us to incorrectly not validate this !dbg
attachment. Fix this by not performing the SP Seen check if Scope == SP
Reviewers: pcc, dexonsmith, dblaikie
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14697
llvm-svn: 254887
 | 
| | 
| 
| 
| 
| 
|  | 
No functional change.
llvm-svn: 254885
 | 
| | 
| 
| 
| 
| 
|  | 
multiple places.
llvm-svn: 254884
 | 
| | 
| 
| 
|  | 
llvm-svn: 254883
 | 
| | 
| 
| 
|  | 
llvm-svn: 254882
 | 
| | 
| 
| 
|  | 
llvm-svn: 254880
 | 
| | 
| 
| 
|  | 
llvm-svn: 254878
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
According to x86 spec, loopz and loopnz should be supported for Intel syntax, where loopz is equivalent to loope and loopnz is equivalent to loopne.
Differential Revision: http://reviews.llvm.org/D15148
llvm-svn: 254877
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D14701
llvm-svn: 254875
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This removes the code path that generate "synchronous" (only correct at call site) CFA.
We will probably want to re-introduce it once we are capable of emitting different
.eh_frame and .debug_frame sections.
Differential Revision: http://reviews.llvm.org/D14948
llvm-svn: 254874
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D15076
llvm-svn: 254873
 | 
| | 
| 
| 
|  | 
llvm-svn: 254872
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
There are `SelectPatternFlavor`s that don't represent min or max idioms,
and we should not be passing those to `getCmpPredicateForMinMax`.
Fixes PR25745.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15249
llvm-svn: 254869
 | 
| | 
| 
| 
|  | 
llvm-svn: 254866
 | 
| | 
| 
| 
|  | 
llvm-svn: 254864
 | 
| | 
| 
| 
|  | 
llvm-svn: 254863
 | 
| | 
| 
| 
|  | 
llvm-svn: 254861
 | 
| | 
| 
| 
|  | 
llvm-svn: 254859
 | 
| | 
| 
| 
|  | 
llvm-svn: 254857
 | 
| | 
| 
| 
| 
| 
|  | 
experiment with.
llvm-svn: 254856
 | 
| | 
| 
| 
| 
| 
|  | 
functions.
llvm-svn: 254855
 |