| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
is used in cases where global symbols are
directly represented in the GOT and we use an
offset into the global offset table.
This patch adds direct object support for R_MIPS_GOT_DISP.
llvm-svn: 160183
|
| |
|
|
| |
llvm-svn: 160173
|
| |
|
|
| |
llvm-svn: 160162
|
| |
|
|
| |
llvm-svn: 160159
|
| |
|
|
|
|
|
|
|
| |
When dumping the DAG for a fatal 'Cannot select' back-end error, also
provide the name of the function the construct is in. Useful when dealing
with large testcases, as the next step is to llvm-extract the function
in question to get a small(er) testcase.
llvm-svn: 160152
|
| |
|
|
|
|
|
|
| |
Fixes PR13303.
Patch by Paul Robinson!
llvm-svn: 160148
|
| |
|
|
| |
llvm-svn: 160142
|
| |
|
|
|
|
|
|
| |
MachineLICM don't touch it.
I already had the necessary things in place for IR-level passes but missed the machine passes.
llvm-svn: 160137
|
| |
|
|
|
|
|
|
|
| |
The rdrand/cmov sequence is the same that is emitted by both
GCC and ICC.
Fixes PR13284.
llvm-svn: 160117
|
| |
|
|
|
|
|
|
|
| |
the input vector, it can be bigger (this is helpful for powerpc where <2 x i16>
is a legal vector type but i16 isn't a legal type, IIRC). However this wasn't
being taken into account by ExpandRes_EXTRACT_VECTOR_ELT, causing PR13220.
Lightly tweaked version of a patch by Michael Liao.
llvm-svn: 160116
|
| |
|
|
|
|
| |
myself and Manman Ren.
llvm-svn: 160110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%shr = lshr i64 %key, 3
%0 = load i64* %val, align 8
%sub = add i64 %0, -1
%and = and i64 %sub, %shr
ret i64 %and
to:
%shr = lshr i64 %key, 3
%0 = load i64* %val, align 8
%sub = add i64 %0, 2305843009213693951
%and = and i64 %sub, %shr
ret i64 %and
The demanded bit optimization is actually a pessimization because add -1 would
be codegen'ed as a sub 1. Teach the demanded constant shrinking optimization
to check for negated constant to make sure it is actually reducing the width
of the constant.
rdar://11793464
llvm-svn: 160101
|
| |
|
|
|
|
|
|
|
|
|
| |
def Pat<...>;
Results in 'record name is not a string!' diagnostic. Not the best,
but the lack of location information moves it from not very helpful
into completely useless. We're in the Record class when throwing the
error, so just add the location info directly.
llvm-svn: 160098
|
| |
|
|
| |
llvm-svn: 160093
|
| |
|
|
|
|
|
|
| |
It is safe if CPSR is killed or re-defined.
When we are done with the basic block, check whether CPSR is live-out.
Do not optimize away cmp if CPSR is live-out.
llvm-svn: 160090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When WriteFragmentData() case FT_align called
Asm.getBackend().writeNopData() is called, nothing
is done since Mips implementation of writeNopData just
returned "true".
For some reason this has not caused problems in 32 bit
mode, but in 64 bit mode it caused an assert when processing
multiple function units.
The test case included will assert without this patch. It
runs twice with different flags to prevent false positives
due to changes in code generation over time.
llvm-svn: 160084
|
| |
|
|
|
|
|
|
| |
Even though variable in question could not
be initialized before use, the code was such that
the compiler had no way of knowing that.
llvm-svn: 160081
|
| |
|
|
|
|
|
|
|
|
|
|
| |
file buffer is null-terminated.
If the file is smaller than we thought, mmap will not allow dereferencing
past the pages that are enough to cover the actual file size,
even though we asked for a larger address range.
rdar://11612916
llvm-svn: 160075
|
| |
|
|
|
|
|
|
| |
order of binary encoding.
Patch by Vladimir Medic.
llvm-svn: 160073
|
| |
|
|
|
|
| |
comments.
llvm-svn: 160069
|
| |
|
|
|
|
|
| |
When Movr0 is between sub and cmp, we move Movr0 before sub if it enables
removal of Cmp.
llvm-svn: 160066
|
| |
|
|
| |
llvm-svn: 160064
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r1025 = s/zext r1024, 4
r1026 = extract_subreg r1025, 4
to a copy:
r1026 = copy r1024
This is correct. However it uses TII->isCoalescableExtInstr() which can return
true for instructions which essentially does a sext_in_reg so this can end up
with an illegal copy where the source and destination register classes do not
match. Add a check to avoid it. Sorry, no test case possible at this time.
rdar://11849816
llvm-svn: 160059
|
| |
|
|
|
|
| |
This caused 6 of 65k possible 8 bit udivs to be wrong.
llvm-svn: 160058
|
| |
|
|
|
|
| |
to Selection DAG isel. Patch by Andrew Kaylor <andrew.kaylor@intel.com>.
llvm-svn: 160055
|
| |
|
|
|
|
| |
allow loads/stores of 64bit values from xmm registers.
llvm-svn: 160044
|
| |
|
|
|
|
|
|
| |
Ptr, etc.
No functionality change.
llvm-svn: 160042
|
| |
|
|
| |
llvm-svn: 160040
|
| |
|
|
|
|
|
| |
Load and Store nodes into their own functions.
No functional change.
llvm-svn: 160037
|
| |
|
|
|
|
|
|
| |
an MVT::i1, i.e. before type legalization.
This is a speculative fix for a problem on Mips reported by Akira Hatanaka.
llvm-svn: 160036
|
| |
|
|
|
|
| |
Patch by Sasa Stankovic.
llvm-svn: 160031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Low order register of a double word register operand. Operands
are defined by the name of the variable they are marked with in
the inline assembler code. This is a way to specify that the
operand just refers to the low order register for that variable.
It is the opposite of modifier 'D' which specifies the high order
register.
Example:
main()
{
long long ll_input = 0x1111222233334444LL;
long long ll_val = 3;
int i_result = 0;
__asm__ __volatile__(
"or %0, %L1, %2"
: "=r" (i_result)
: "r" (ll_input), "r" (ll_val));
}
Which results in:
lui $2, %hi(_gp_disp)
addiu $2, $2, %lo(_gp_disp)
addiu $sp, $sp, -8
addu $2, $2, $25
sw $2, 0($sp)
lui $2, 13107
ori $3, $2, 17476 <-- Low 32 bits of ll_input
lui $2, 4369
ori $4, $2, 8738 <-- High 32 bits of ll_input
addiu $5, $zero, 3 <-- Low 32 bits of ll_val
addiu $2, $zero, 0 <-- High 32 bits of ll_val
#APP
or $3, $4, $5 <-- or i_result, high 32 ll_input, low 32 of ll_val
#NO_APP
addiu $sp, $sp, 8
jr $ra
If not direction is done for the long long for 32 bit variables results
in using the low 32 bits as ll_val shows.
There is an existing bug if 'L' or 'D' is used for the destination register
for 32 bit long longs in that the target value will be updated incorrectly
for the non-specified part unless explicitly set within the inline asm code.
llvm-svn: 160028
|
| |
|
|
|
|
| |
It will surely be needed by heuristics.
llvm-svn: 160027
|
| |
|
|
|
|
|
|
|
|
|
| |
generalizing its implementation sufficiently to support this value
number scenario as well.
This cuts out another significant performance hit in large functions
(over 10k basic blocks, etc), especially those with "natural" CFG
structures.
llvm-svn: 160026
|
| |
|
|
|
|
|
|
|
|
|
| |
This ordering allows nested if-conversion without using a work list, and
it makes it possible to update the dominator tree on the fly as well.
Any erased basic blocks will always be dominated by the current
post-order position, so the domtree can be pruned without invalidating
the iterator.
llvm-svn: 160025
|
| |
|
|
|
|
|
| |
X86MachineFunctionInfo as this is currently only used by X86. If this ever
becomes an issue on another arch (e.g., ARM) then we can hoist it back out.
llvm-svn: 160009
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
X86. Basically, this is a reapplication of r158087 with a few fixes.
Specifically, (1) the stack pointer is restored from the base pointer before
popping callee-saved registers and (2) in obscure cases (see comments in patch)
we must cache the value of the original stack adjustment in the prologue and
apply it in the epilogue.
rdar://11496434
llvm-svn: 160002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
back of it.
I don't have anything even remotely close to a test case for this. It
only broke two build bots, both of them doing bootstrap builds, one of
them a dragonegg bootstrap. It doesn't break for me when I bootstrap
either. It doesn't reproduce every time or on many machines during the
bootstrap. Many thanks to Duncan Sands who got the exact command (and
stage of the bootstrap) which failed on the dragonegg bootstrap and
managed to get it to trigger under valgrind with debug symbols. The fix
was then found by inspection.
llvm-svn: 159993
|
| |
|
|
|
|
|
|
|
| |
multiple scalars and insert them into a vector. Next, we shuffle the elements
into the correct places, as before.
Also fix a small dagcombine bug in SimplifyBinOpWithSameOpcodeHands, when the
migration of bitcasts happened too late in the SelectionDAG process.
llvm-svn: 159991
|
| |
|
|
|
|
| |
single-precision resiters) (and do it properly this time!
llvm-svn: 159989
|
| |
|
|
| |
llvm-svn: 159983
|
| |
|
|
|
|
|
|
|
|
|
| |
quadratic behavior when performing pathological merges. Fixes the core
element of PR12652.
There is only one user of addRangeFrom left: join. I'm hoping to
refactor further in a future patch and have join use this merge
operation as well.
llvm-svn: 159982
|
| |
|
|
|
|
|
|
|
|
| |
of the trick merge routines. This adds a layer of testing that was
necessary when implementing more efficient (and complex) merge logic for
this datastructure.
No functionality changed here.
llvm-svn: 159981
|
| |
|
|
|
|
|
|
|
| |
Some NEON instructions want to match against normal SDNodes for some
operand types and Intrinsics for others. For example, CTLZ. To enable this,
switch from explicitly requiring Intrinsic on the class templates to using
SDPatternOperator instead.
llvm-svn: 159974
|
| |
|
|
| |
llvm-svn: 159971
|
| |
|
|
|
|
| |
obscure ways, and it isn't actually important in the real world.
llvm-svn: 159969
|
| |
|
|
| |
llvm-svn: 159960
|
| |
|
|
| |
llvm-svn: 159958
|
| |
|
|
|
|
|
|
| |
move, since there are only two possible values.
Previously, this would become an integer extension operation, followed by a real integer->float conversion.
llvm-svn: 159957
|
| |
|
|
|
|
|
|
|
|
|
| |
getCondFromSETOpc, getCondFromCMovOpc, getSETFromCond, getCMovFromCond
No functional change intended.
If we want to update the condition code of CMOV|SET|Jcc, we first analyze the
opcode to get the condition code, then update the condition code, finally
synthesize the new opcode form the new condition code.
llvm-svn: 159955
|