| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21128
llvm-svn: 272172
|
| |
|
|
| |
llvm-svn: 272171
|
| |
|
|
|
|
|
|
|
|
| |
Teach AArch64RegisterBankInfo that G_OR can be mapped on either GPR or
FPR for 64-bit or 32-bit values.
Add test cases demonstrating how this information is used to coalesce a
computation on a single register bank.
llvm-svn: 272170
|
| |
|
|
|
|
|
| |
The RegBankSelect pass can now rely on the target to do the remapping of
the instructions.
llvm-svn: 272169
|
| |
|
|
|
|
|
| |
The new version of the header introduces the INSTR_PROF_VISIBILITY
macro. See http://reviews.llvm.org/D21116 for more details.
llvm-svn: 272166
|
| |
|
|
|
|
|
|
|
| |
Now, the target will be able to provide its how implementation to remap
an instruction. This open the way to crazier optimizations, but to
beginning with, we will be able to handle something else than the
default mapping.
llvm-svn: 272165
|
| |
|
|
|
|
|
|
|
| |
Now that we have an entity that hold the remap information the
rewritting should be easier to do.
No functional changes.
llvm-svn: 272164
|
| |
|
|
|
|
|
| |
The repairing code has no reason to change the source or destination of
the registers.
llvm-svn: 272163
|
| |
|
|
|
|
|
| |
This helper class is used to encapsulate the necessary information
to remap an instruction.
llvm-svn: 272161
|
| |
|
|
|
|
| |
This G_OR is used in GlobalISel to represent bitwise OR.
llvm-svn: 272160
|
| |
|
|
|
|
|
|
|
|
| |
When the command line option is set, it overrides any thing that the
target may have set. The rationale is that we get what we asked for.
Options are respectively regbankselect-fast and regbankselect-greedy for
fast and greedy mode.
llvm-svn: 272158
|
| |
|
|
|
|
|
|
|
|
|
| |
repairing.
Copies are easy because we repair only when there is a mismatch. For
non-copy repairing, i.e., cases that involves breaking down or gathering
up the value, one of the operand may not have a register bank yet. Thus,
derivate a cost from that, requires more work.
llvm-svn: 272157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MSR instructions can write to the CPSR, but we did not model this
fact, so we could emit them in the middle of IT blocks, changing the
condition flags for later instructions in the block.
The tests use two calls to llvm.write_register.i32 because it is valid
to use these instructions at the end of an IT block, which if conversion
does do in some cases. With two calls, the first clobbers the flags, so
a branch has to be used to make the second one conditional.
Differential Revision: http://reviews.llvm.org/D21139
llvm-svn: 272154
|
| |
|
|
| |
llvm-svn: 272147
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The architecture enumeration is shared across ARM and AArch64. However, the
data is not. The code incorrectly would index into the array using the
architecture index which was offset by the ARMv7 architecture enumeration. We
do not have a marker for indicating the architectural family to which the
enumeration belongs so we cannot be clever about offsetting the index (at least
it is not immediately apparent to me). Instead, fall back to the tried-and-true
method of slowly iterating the array (its not a large array, so the impact of
this is not too high).
Because of the incorrect indexing, if we were lucky, we would crash, but usually
we would return an invalid StringRef. We did not have any tests for the AArch64
target parser previously;. Extend the previous tests I had added for ARM to
cover AArch64 for ensuring that we return expected StringRefs.
Take the opportunity to change some iterator types to references.
This work is needed to support parsing `.arch name` directives in the AArch64
target asm parser.
llvm-svn: 272145
|
| |
|
|
| |
llvm-svn: 272140
|
| |
|
|
| |
llvm-svn: 272139
|
| |
|
|
| |
llvm-svn: 272138
|
| |
|
|
|
|
|
|
|
| |
Also, switch to using functions from LiveIntervalAnalysis to update
live intervals, instead of performing the updates manually.
Re-committing r272045.
llvm-svn: 272135
|
| |
|
|
|
|
| |
isSwift is tested earlier and known to be false when we reach this code.
llvm-svn: 272127
|
| |
|
|
|
|
|
|
| |
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
llvm-svn: 272126
|
| |
|
|
| |
llvm-svn: 272122
|
| |
|
|
| |
llvm-svn: 272117
|
| |
|
|
| |
llvm-svn: 272116
|
| |
|
|
|
|
| |
the coverage rt (it should now fail with a descriptive message)
llvm-svn: 272090
|
| |
|
|
|
|
| |
-DLLVM_ENABLE_ASSERTIONS=ON
llvm-svn: 272088
|
| |
|
|
|
|
| |
Long term we may want to give high cost at FPR to/from GPR copies.
llvm-svn: 272086
|
| |
|
|
|
|
|
|
| |
The generic implementation stated that all copies were free, which is
unlikely. Now, only the copies within the same register bank are free.
We assume they will get coalesced.
llvm-svn: 272085
|
| |
|
|
|
|
|
| |
The cost of a copy may be different based on how many bits we have to
copy around. E.g., a 8-bit copy may be different than a 32-bit copy.
llvm-svn: 272084
|
| |
|
|
|
|
| |
This will allow code reuse in the coming commits.
llvm-svn: 272083
|
| |
|
|
|
|
|
| |
The MachineMemOperand parser lacked the code to handle %stack.X
references (%fixed-stack.X was working).
llvm-svn: 272082
|
| |
|
|
| |
llvm-svn: 272078
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We were previously failing to do this and as a result failing to drop
attached metadata.
Not sure if there's a good way to test this. An in-progress patch exposed this
problem by allocating a GlobalVariable at the same address as a previously
allocated GlobalVariable.
Differential Revision: http://reviews.llvm.org/D21109
llvm-svn: 272077
|
| |
|
|
|
|
| |
In the reference code, the field name is `cHashBuckets`.
llvm-svn: 272075
|
| |
|
|
| |
llvm-svn: 272073
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes linking problems on OSX.
Unfortunately it turns out we need to use an instance of the
``fuzzer::ExternalFunctions`` object in several places so this
commit also replaces all instances with a single global instance.
It also turns out initializing a global ``fuzzer::ExternalFunctions``
before main is entered (i.e. letting the object be initialised by the
global initializers) is not safe (on OSX the call to ``Printf()`` in the
CTOR crashes if it is called from a global initializer) so we instead
have a global ``fuzzer::ExternalFunctions*`` and initialize it inside
``FuzzerDriver()``.
Multiple unit tests depend also depend on the
``fuzzer::ExternalFunctions*`` global so a ``main()`` function has been
added that initializes it before running any tests.
Differential Revision: http://reviews.llvm.org/D20943
llvm-svn: 272072
|
| |
|
|
|
|
| |
SourceBasedCodeCoverage.html in libFuzzer docs
llvm-svn: 272070
|
| |
|
|
|
|
|
|
|
|
| |
Changes since the initial commit:
- Use echo instead of printf. This should side-step the character
escaping issues on Windows.
Differential Revision: http://reviews.llvm.org/D20980
llvm-svn: 272068
|
| |
|
|
| |
llvm-svn: 272066
|
| |
|
|
| |
llvm-svn: 272065
|
| |
|
|
|
|
|
|
| |
Also use default/delete instead of hand-written ctors.
Thanks to Jia Chen for bringing this stuff up.
llvm-svn: 272064
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The presence of this attribute indicates that VGPR outputs should be computed
in whole quad mode. This will be used by Mesa for prolog pixel shaders, so
that derivatives can be taken of shader inputs computed by the prolog, fixing
a bug.
The generated code could certainly be improved: if a prolog pixel shader is
used (which isn't common in modern OpenGL - they're used for gl_Color, polygon
stipples, and forcing per-sample interpolation), Mesa will use this attribute
unconditionally, because it has to be conservative. So WQM may be used in the
prolog when it isn't really needed, and furthermore a silly back-and-forth
switch is likely to happen at the boundary between prolog and main shader
parts.
Fixing this is a bit involved: we'd first have to add a mechanism by which
LLVM writes the WQM-related input requirements to the main shader part binary,
and then Mesa specializes the prolog part accordingly. At that point, we may
as well just compile a monolithic shader...
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95130
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D20839
llvm-svn: 272063
|
| |
|
|
|
|
|
|
|
|
| |
This is necessary because the existing fuzzer-oom.test was Linux
specific due to its use of __sanitizer_print_memory_profile() which
is only available on Linux right now and so the test would fail on OSX.
Differential Revision: http://reviews.llvm.org/D20977
llvm-svn: 272061
|
| |
|
|
|
|
| |
There are no VEX encoded versions of SSE4A instructions, make sure that AVX targets give the same output
llvm-svn: 272060
|
| |
|
|
| |
llvm-svn: 272059
|
| |
|
|
| |
llvm-svn: 272058
|
| |
|
|
|
|
|
| |
Adds some discussion of the nature of the format, and some developer
docs on how to work with it in LLVM.
llvm-svn: 272057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Author: Wei Ding <wei.ding2@amd.com>
Date: Tue Jun 7 19:04:44 2016 +0000
Differential Revision: http://reviews.llvm.org/D20557
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272044
91177308-0d34-0410-b5e6-96231b3b80d8
as it was breaking the bots.
This reverts commit r272044.
llvm-svn: 272056
|
| |
|
|
| |
llvm-svn: 272055
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21089
llvm-svn: 272054
|