| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will allow its use inside of memcpy rewriting as well. This routine
is more complex than extractVector, and some of its uses are not 100%
where I want them to be so there is still some work to do here.
While this can technically change the output in some cases, it shouldn't
be a change that matters -- IE, it can leave some dead code lying around
that prior versions did not, etc.
Yet another step in the refactorings leading up to the solution to the
last component of PR14478.
llvm-svn: 170328
|
| |
|
|
|
|
| |
Previously these were marked with the wrong format.
llvm-svn: 170327
|
| |
|
|
| |
llvm-svn: 170326
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method helpers all implicitly act upon the alloca, and what we
really want is a fully generic helper. Doing memcpy rewrites is more
special than all other rewrites because we are at times rewriting
instructions which touch pointers *other* than the alloca. As
a consequence all of the helpers needed by memcpy rewriting of
sub-vector copies will need to be generalized fully.
Note that all of these helpers ({insert,extract}{Integer,Vector}) are
woefully uncommented. I'm going to go back through and document them
once I get the factoring correct.
No functionality changed.
llvm-svn: 170325
|
| |
|
|
|
|
|
|
|
| |
This makes it suitable for use in rewriting memcpy in the presence of
subvector memcpy intrinsics.
No functionality changed.
llvm-svn: 170324
|
| |
|
|
| |
llvm-svn: 170323
|
| |
|
|
| |
llvm-svn: 170322
|
| |
|
|
| |
llvm-svn: 170321
|
| |
|
|
| |
llvm-svn: 170320
|
| |
|
|
| |
llvm-svn: 170319
|
| |
|
|
|
|
| |
Patch by Chris Toshok.
llvm-svn: 170318
|
| |
|
|
| |
llvm-svn: 170317
|
| |
|
|
|
|
|
|
|
| |
More specifically:
- Improve formatting of static initializers.
- Fix formatting of lines comments in enums.
- Fix formmating of trailing line comments.
llvm-svn: 170316
|
| |
|
|
| |
llvm-svn: 170315
|
| |
|
|
| |
llvm-svn: 170314
|
| |
|
|
| |
llvm-svn: 170313
|
| |
|
|
|
|
| |
Capturing thread name during profiling.
llvm-svn: 170312
|
| |
|
|
| |
llvm-svn: 170311
|
| |
|
|
|
|
| |
stacks work
llvm-svn: 170310
|
| |
|
|
| |
llvm-svn: 170309
|
| |
|
|
|
|
| |
combine don't contain an EFLAGS def.
llvm-svn: 170308
|
| |
|
|
|
|
| |
add ANDN to isDefConvertible.
llvm-svn: 170305
|
| |
|
|
|
|
| |
and lzcnt.
llvm-svn: 170304
|
| |
|
|
|
|
| |
they don't have a register def.
llvm-svn: 170303
|
| |
|
|
|
|
|
|
|
|
| |
incompatibility with how complex values are returned. It is sufficient
to flag all complex types as direct rather than indirect.
A new test case is provided that checks correct IR generation for the
various supported flavors of _Complex.
llvm-svn: 170302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR14478 highlights a serious problem in SROA that simply wasn't being
exercised due to a lack of vector input code mixed with C-library
function calls. Part of SROA was written carefully to handle subvector
accesses via memset and memcpy, but the rewriter never grew support for
this. Fixing it required refactoring the subvector access code in other
parts of SROA so it could be shared, and then fixing the splat formation
logic and using subvector insertion (this patch).
The PR isn't quite fixed yet, as memcpy is still broken in the same way.
I'm starting on that series of patches now.
Hopefully this will be enough to bring the bullet benchmark back to life
with the bb-vectorizer enabled, but that may require fixing memcpy as
well.
llvm-svn: 170301
|
| |
|
|
|
|
|
| |
No functionality changed. Another step of refactoring toward solving
PR14487.
llvm-svn: 170300
|
| |
|
|
|
|
|
|
| |
No functionality changed. Refactoring leading up to the fix for PR14478
which requires some significant changes to the memset and memcpy
rewriting.
llvm-svn: 170299
|
| |
|
|
| |
llvm-svn: 170298
|
| |
|
|
| |
llvm-svn: 170297
|
| |
|
|
| |
llvm-svn: 170296
|
| |
|
|
| |
llvm-svn: 170295
|
| |
|
|
| |
llvm-svn: 170294
|
| |
|
|
| |
llvm-svn: 170293
|
| |
|
|
|
|
|
|
| |
Currently there is no instruction encoding info and
XCoreDisassembler::getInstruction() always returns Fail. I intend to add
instruction encodings and tests in follow on commits.
llvm-svn: 170292
|
| |
|
|
| |
llvm-svn: 170291
|
| |
|
|
| |
llvm-svn: 170290
|
| |
|
|
| |
llvm-svn: 170289
|
| |
|
|
|
|
|
| |
This change adds XCoreMCInstLower to do the lowering to MCInst and
XCoreInstPrinter to print the MCInsts.
llvm-svn: 170288
|
| |
|
|
| |
llvm-svn: 170286
|
| |
|
|
|
|
|
|
| |
from some other unrelated header.
Patch by Kai.
llvm-svn: 170284
|
| |
|
|
|
|
| |
This enables us to use the same document structure as in other files.
llvm-svn: 170283
|
| |
|
|
|
|
| |
end of the cache. Fixes PR14570.
llvm-svn: 170281
|
| |
|
|
| |
llvm-svn: 170280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mips16 is really a processor decoding mode (ala thumb 1) and in the same
program, mips16 and mips32 functions can exist and can call each other.
If a jal type instruction encounters an address with the lower bit set, then
the processor switches to mips16 mode (if it is not already in it). If the
lower bit is not set, then it switches to mips32 mode.
The linker knows which functions are mips16 and which are mips32.
When relocation is performed on code labels, this lower order bit is
set if the code label is a mips16 code label.
In general this works just fine, however when creating exception handling
tables and dwarf, there are cases where you don't want this lower order
bit added in.
This has been traditionally distinguished in gas assembly source by using a
different syntax for the label.
lab1: ; this will cause the lower order bit to be added
lab2=. ; this will not cause the lower order bit to be added
In some cases, it does not matter because in dwarf and debug tables
the difference of two labels is used and in that case the lower order
bits subtract each other out.
To fix this, I have added to mcstreamer the notion of a debuglabel.
The default is for label and debug label to be the same. So calling
EmitLabel and EmitDebugLabel produce the same result.
For various reasons, there is only one set of labels that needs to be
modified for the mips exceptions to work. These are the "$eh_func_beginXXX"
labels.
Mips overrides the debug label suffix from ":" to "=." .
This initial patch fixes exceptions. More changes most likely
will be needed to DwarfCFException to make all of this work
for actual debugging. These changes will be to emit debug labels in some
places where a simple label is emitted now.
Some historical discussion on this from gcc can be found at:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00623.html
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01273.html
llvm-svn: 170279
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The adornment:
===
Foo
===
is for titles, not sections.
llvm-svn: 170278
|
| |
|
|
|
|
| |
highlight console output with "code-block:: console", etc.
llvm-svn: 170276
|
| |
|
|
|
|
| |
Patch by Anastasi Voitova with with small fixes by me.
llvm-svn: 170275
|
| |
|
|
|
|
| |
SEGV on allocations between 1Mb and 2Mb, improve the test
llvm-svn: 170274
|
| |
|
|
|
|
|
|
|
|
|
| |
psubus if possible.
We match the pattern "x >= y ? x-y : 0" into "subus x, y" and two special cases
if y is a constant. DAGCombiner canonicalizes those so we first have to undo the
canonicalization for those cases. The pattern occurs in gzip when the loop
vectorizer is enabled. Part of PR14613.
llvm-svn: 170273
|