| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This instruction is encoded as zero, so we have handle that case when checking
for unimplemented opcodes when producing the encoding for an instruction.
llvm-svn: 321066
|
| |
|
|
|
|
| |
are smoke only.
llvm-svn: 321065
|
| |
|
|
|
|
|
|
|
|
|
| |
Before this patch, dwarfdump's lookup parameter only accepts unsigned.
Given that for many current platforms the load address already exceeds
unsigned (e.g. arm64 w/ 0x100000000), dwarfdump needs an unsigned long
long parameter.
Patch by: Dr. Michael 'Mickey' Lauer <mickey@vanille-media.de>
llvm-svn: 321064
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
successors
PRE in JumpThreading should not be able to hoist copy of non-speculable loads across
instructions that don't always transfer execution to their successors, otherwise they may
introduce an unsafe load which otherwise would not be executed.
The same problem for GVN was fixed as rL316975.
Differential Revision: https://reviews.llvm.org/D40347
llvm-svn: 321063
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41009
llvm-svn: 321062
|
| |
|
|
|
|
|
|
|
|
|
|
| |
getPointerDereferenceableBytes()
Reviewers: rnk, hfinkel, efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41355
llvm-svn: 321061
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Sanitizers on NetBSD require additional linkage:
- libutil for forkpty(3)
- libexecinfo for backtrace(3)
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, eugenis, vitalybuka, kcc
Reviewed By: eugenis
Subscribers: #sanitizers, cfe-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D41054
llvm-svn: 321060
|
| |
|
|
|
|
|
|
| |
v16i16 instead.
BWI supports shifting by word amounts. Even if VLX isn't support we can still widen to v32i16 and extract the lower half. For SKX its preferrable to not use 512-bit vector if we can.
llvm-svn: 321059
|
| |
|
|
|
|
|
|
| |
iterating over every integer VT and checking their size.
Previously, we were checking for MVTs with sizes betwen 8 and 64 which only includes i8, i16, i32, and i64 today. But I don't think we should assume that and should list the types that are legal for x86. I also don't think we need i64 since type legalization is guaranteed to split those up.
llvm-svn: 321058
|
| |
|
|
|
|
| |
I doubt there's any way to create a ashr for an FP type.
llvm-svn: 321057
|
| |
|
|
|
|
|
|
| |
zero vector.
Pretty sure these are handled by a target independent DAG combine that turns them into undef these days.
llvm-svn: 321056
|
| |
|
|
|
|
|
|
|
|
| |
for a non-uniform shift.
My reading of the SDM says that all bits of the shift amount are used. If the value of the element is larger than the number of bits the result the shift result is zero. So I think we need to zero_extend here to avoid garbage in the upper bits.
In reality we lower any_extend as zero_extend so in most cases it would be hard to hit this.
llvm-svn: 321055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method IEEEFloat::convertFromStringSpecials() does not recognize
the "+Inf" and "-Inf" strings but these strings are printed for
the double Infinities by the IEEEFloat::toString().
This patch adds the "+Inf" and "-Inf" strings to the list of recognized
patterns in IEEEFloat::convertFromStringSpecials().
Re-landing after fix.
Reviewers: sberg, bogner, majnemer, timshen, rnk, skatkov, gottesmm, bkramer, scanon, anna
Reviewed By: anna
Subscribers: mkazantsev, FlameTop, llvm-commits, reames, apilipenko
Differential Revision: https://reviews.llvm.org/D38030
llvm-svn: 321054
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the emission
Between the creation of the last InstructionMatcher and the first
emission of the related Rule, we need to clear the internal map of IDs.
We used to do that right after the creation of the main
InstructionMatcher when building the rule and although that worked, this
is fragile because if for some reason some later code decides to create
more InstructionMatcher before the final call to emit, then the IDs
would be completely messed up.
Move that to the beginning of "emit" so that the IDs are guarantee to be
consistent.
NFC.
llvm-svn: 321053
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes regression from r320533.
This fixes the undefined behavior, but I'm not sure it's really right...
I think we end up with missing coverage for code in modules.
Differential Revision: https://reviews.llvm.org/D41374
llvm-svn: 321052
|
| |
|
|
|
|
|
| |
file. For macos builds specifically, use the macosx entitlements
files; for all other builds, use the ios etc entitlements.
llvm-svn: 321051
|
| |
|
|
|
|
|
| |
This array is tightly coupled with the .def file. Someone should look
into fixing that.
llvm-svn: 321050
|
| |
|
|
|
|
| |
The test was using both // and # before.
llvm-svn: 321049
|
| |
|
|
|
|
|
|
| |
We need to handle IR for tests that want to do lowering (or just
-stop-after with IR as input). I've run this on one AArch64 test to
demonstrate what it looks like.
llvm-svn: 321048
|
| |
|
|
|
|
|
|
| |
This change adds support for adding progbits sections with contents from a file
Differential Revision: https://reviews.llvm.org/D41212
llvm-svn: 321047
|
| |
|
|
|
|
|
|
|
| |
I missed some prefixes and the fact that on AArch64 we use "bzero"
instead of "__bzero" as on X86 when doing my refactoring in r321035.
Improve tests for bzero.
llvm-svn: 321046
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
InitLibcalls()
I missed the fact that the later called InitLibcallCallingConvs()
overrides some things set in InitLibcalls() when I did the refactoring
in r321036.
Fix by merging InitLibcallCallingConvs() into InitLibcalls() and doing
the initialization earlier.
llvm-svn: 321045
|
| |
|
|
| |
llvm-svn: 321044
|
| |
|
|
|
|
|
| |
This problem was present for a while, but somehow asan didn't catch
it before the refactoring in r321036.
llvm-svn: 321043
|
| |
|
|
| |
llvm-svn: 321042
|
| |
|
|
|
|
|
| |
WatchOS isn't report as iOS (as opposed to tvos) so the exception I
added in my last commit wasn't necessary after all.
llvm-svn: 321041
|
| |
|
|
|
|
|
|
| |
longer generate a long nop on x86.
Long nops aren't supported by all x86 CPUs. So if no CPU is specified we have to use a single byte nop.
llvm-svn: 321040
|
| |
|
|
|
|
|
| |
For tests that do lowering we need to support IR as input, so here we
clarify some names to avoid ambiguity in upcoming commits.
llvm-svn: 321039
|
| |
|
|
|
|
| |
This recommits the change from r321026. I have a fix for the lld test now.
llvm-svn: 321038
|
| |
|
|
|
|
| |
Filenames should match the name of the class they contain.
llvm-svn: 321037
|
| |
|
|
|
|
|
|
|
|
|
| |
Note:
- X86ISelLowering: setLibcallName(SINCOS) was superfluous as
InitLibcalls() already does it.
- ARMISelLowering: Setting libcallnames for sincos/sincosf seemed
superfluous as in the darwin case it wouldn't be used while for all
other cases InitLibcalls already does it.
llvm-svn: 321036
|
| |
|
|
| |
llvm-svn: 321035
|
| |
|
|
| |
llvm-svn: 321034
|
| |
|
|
|
|
|
|
| |
empty CPU string." while I investigate how to fix an lld test failure.
Looks like lld also needs to pass a -mcpu in some of its tests
llvm-svn: 321033
|
| |
|
|
|
|
| |
Make sure that all test cases are run for Exynos as well. Otherwise, NFC.
llvm-svn: 321032
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Matchers consistent
Move InsnVarID and OpIdx at the beginning of the list of arguments
for all the constructors of the OperandMatcher subclasses.
This matches what we do for the InstructionMatcher.
NFC.
llvm-svn: 321031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were using sprintf(..., "$R06X", <some uint32_t>) to create strings
that are expected to be exactly length 8, but this results in longer
strings if the uint32_t is greater than 0xffffff. This change modifies
the behavior as follows:
- Uses the loop counter instead of the data offset. This gives us
sequential symbol names, avoiding collisions as much as possible.
- Masks the value to 0xffffff to avoid generating names longer than 8
bytes.
- Uses formatv instead of sprintf.
Fixes PR35581.
Reviewers: ruiu, zturner
Reviewed By: ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41270
llvm-svn: 321030
|
| |
|
|
|
|
| |
Reduced test case from libjpeg_turbo.
llvm-svn: 321029
|
| |
|
|
|
|
|
| |
River Riddle suggested to use std::any_of instead of the bool + loop thing on
r320229. This commit does that.
llvm-svn: 321028
|
| |
|
|
| |
llvm-svn: 321027
|
| |
|
|
|
|
|
|
|
|
| |
Update tests to force a CPU with NOPL
Empty string should be equivalent to "generic" which doesn't allow NOPL. Force tests to use specificy 'pentiumpro' to guarantee NOPL.
Fixes PR35686
llvm-svn: 321026
|
| |
|
|
|
|
|
|
|
|
|
| |
In theory, reapplying optimizeRules on each group matchers should give
us a second nesting level on the matching table. In practice, we need
more work to make that happen because all the predicates are actually
not directly available through the predicate matchers list.
NFC.
llvm-svn: 321025
|
| |
|
|
|
|
|
|
|
|
| |
This reverts changes r320992, r320986, r320973, and r320970.
r320970 by itself breaks the test case, and the rest depend on it.
Test case will land soon.
llvm-svn: 321024
|
| |
|
|
|
|
|
|
| |
It is not necessary and matches what bfd and gold do.
This was a regression from r315658.
llvm-svn: 321023
|
| |
|
|
| |
llvm-svn: 321022
|
| |
|
|
|
|
| |
This also changed in r315658. The new result is the correct one.
llvm-svn: 321021
|
| |
|
|
| |
llvm-svn: 321020
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are cases when two tags with different base types denote
accesses to the same direct or indirect member of a structure
type. Currently, merging of such tags results in a tag that
represents an access to an object that has the type of that
member. This patch changes this so that if one of the accesses
encloses the other, then the generic tag is the one of the
enclosed access.
Differential Revision: https://reviews.llvm.org/D39557
llvm-svn: 321019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In r277849, getEntryCount was changed to return None when the entry
count was 0, specifically for SamplePGO where it means no samples were
recorded. However, for instrumentation PGO a 0 entry count should be
returned directly, since it does mean that the function was completely
cold. Otherwise we end up treating these functions conservatively
in isFunctionEntryCold() and isColdBB().
Instead, for SamplePGO use -1 when there are no samples, and change
getEntryCount to return None when the value is -1.
Reviewers: danielcdh, davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41307
llvm-svn: 321018
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Context ***
Prior to this patchw, the table generated for matching instruction was
straight forward but highly inefficient.
Basically, each pattern generates its own set of self contained checks
and actions.
E.g., TableGen generated:
// First pattern
CheckNumOperand 3
CheckOpcode G_ADD
...
Build ADDrr
// Second pattern
CheckNumOperand 3
CheckOpcode G_ADD
...
Build ADDri
// Third pattern
CheckNumOperand 3
CheckOpcode G_SUB
...
Build SUBrr
*** Problem ***
Because of that generation, a *lot* of check were redundant between each
pattern and were checked every single time until we reach the pattern
that matches.
E.g., Taking the previous table, let say we are matching a G_SUB, that
means we were going to check all the rules for G_ADD before looking at
the G_SUB rule. In particular we are going to do:
check 3 operands; PASS
check G_ADD; FAIL
; Next rule
check 3 operands; PASS (but we already knew that!)
check G_ADD; FAIL (well it is still not true)
; Next rule
check 3 operands; PASS (really!!)
check G_SUB; PASS (at last :P)
*** Proposed Solution ***
This patch introduces a concept of group of rules (GroupMatcher) that
share some predicates and only get checked once for the whole group.
This patch only creates groups with one nesting level. Conceptually
there is nothing preventing us for having deeper nest level. However,
the current implementation is not smart enough to share the recording
(aka capturing) of values. That limits its ability to do more sharing.
For the given example the current patch will generate:
// First group
CheckOpcode G_ADD
// First pattern
CheckNumOperand 3
...
Build ADDrr
// Second pattern
CheckNumOperand 3
...
Build ADDri
// Second group
CheckOpcode G_SUB
// Third pattern
CheckNumOperand 3
...
Build SUBrr
But if we allowed several nesting level, it could create a sub group
for the checknumoperand 3.
(We would need to call optimizeRules on the rules within a group.)
*** Result ***
With only one level of nesting, the instruction selection pass is up
to 4x faster. For instance, one instruction now takes 500 checks,
instead of 24k! With more nesting we could get in the tens I believe.
Differential Revision: https://reviews.llvm.org/D39034
rdar://problem/34670699
llvm-svn: 321017
|