| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This fixes a TODO from 2007 :) Previously, LLVM would emit the wrong
code here (see the update to test/CodeGen/X86/tls-pie.ll).
llvm-svn: 156611
|
|
|
|
|
|
| |
instruction. It is now set to 0. The patch also sets the unpredictable mask for SEL and SXTB-type instructions.
llvm-svn: 156609
|
|
|
|
|
|
| |
offset addressing. The assembler and instruction printer were not properly handeling the #-0 immediate.
llvm-svn: 156608
|
|
|
|
| |
llvm-svn: 156606
|
|
|
|
| |
llvm-svn: 156603
|
|
|
|
| |
llvm-svn: 156602
|
|
|
|
| |
llvm-svn: 156601
|
|
|
|
| |
llvm-svn: 156600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will optimize the following cases:
sub r1, r3 | sub r1, imm
cmp r3, r1 or cmp r1, r3 | cmp r1, imm
bge L1
TO
subs r1, r3
bge L1 or ble L1
If the branch instruction can use flag from "sub", then we can replace
"sub" with "subs" and eliminate the "cmp" instruction.
rdar: 10734411
llvm-svn: 156599
|
|
|
|
|
|
| |
but it generates int3 on x86 instead of ud2.
llvm-svn: 156593
|
|
|
|
|
|
|
|
| |
to user only read/write.
Part of rdar://11325849
llvm-svn: 156591
|
|
|
|
| |
llvm-svn: 156589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sub-registers explicitly listed in SubRegs in the .td files form a
tree. In a complicated register bank, it is possible to have
sub-register relationships across sub-trees. For example, the ARM NEON
double vector Q0_Q1 is a tree:
Q0_Q1 = [Q0, Q1], Q0 = [D0, D1], Q1 = [D2, D3]
But we also define the DPair register D1_D2 = [D1, D2] which is fully
contained in Q0_Q1.
This patch teaches TableGen to find such sub-register relationships, and
assign sub-register indices to them. In the example, TableGen will
create a dsub_1_dsub_2 sub-register index, and add D1_D2 as a
sub-register of Q0_Q1.
This will eventually enable the coalescer to handle copies of skewed
sub-registers.
llvm-svn: 156587
|
|
|
|
|
|
| |
add an additional parameter to InstCombiner::EmitGEPOffset() to force it to *not* emit operations with NUW flag
llvm-svn: 156585
|
|
|
|
| |
llvm-svn: 156579
|
|
|
|
|
|
| |
Patch by Jack Carter.
llvm-svn: 156577
|
|
|
|
| |
llvm-svn: 156576
|
|
|
|
| |
llvm-svn: 156575
|
|
|
|
|
|
|
|
|
|
|
| |
Prioritize the instruction that comes closest to keeping pressure
under the target's limit. Then prioritize instructions that avoid
increasing the max pressure in the scheduled region. The max pressure
heuristic is a tad aggressive. Later I'll fix it to consider the
unscheduled pressure as well.
WIP: This is mostly functional but untested and not likely to do much good yet.
llvm-svn: 156574
|
|
|
|
| |
llvm-svn: 156573
|
|
|
|
| |
llvm-svn: 156572
|
|
|
|
|
|
| |
scheduling.
llvm-svn: 156571
|
|
|
|
| |
llvm-svn: 156569
|
|
|
|
| |
llvm-svn: 156568
|
|
|
|
|
|
|
|
|
| |
Added getMaxExcessUpward/DownwardPressure. They somewhat abuse the
tracker by speculatively handling an instruction out of order. But it
is convenient for now. In the future, we will cache each instruction's
pressure contribution to make this efficient.
llvm-svn: 156561
|
|
|
|
| |
llvm-svn: 156560
|
|
|
|
| |
llvm-svn: 156558
|
|
|
|
|
|
| |
This commit broke an external linux bot and gave a compile-time warning.
llvm-svn: 156556
|
|
|
|
|
|
|
|
| |
The .td files specify a tree of sub-registers. Store that tree as
ExplicitSubRegs lists in CodeGenRegister instead of extracting it from
the Record when needed.
llvm-svn: 156555
|
|
|
|
|
|
| |
of recursion, to avoid excessive stack usage on deep expressions.
llvm-svn: 156554
|
|
|
|
| |
llvm-svn: 156553
|
|
|
|
| |
llvm-svn: 156551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will optimize the following cases:
sub r1, r3 | sub r1, imm
cmp r3, r1 or cmp r1, r3 | cmp r1, imm
bge L1
TO
subs r1, r3
bge L1 or ble L1
If the branch instruction can use flag from "sub", then we can replace
"sub" with "subs" and eliminate the "cmp" instruction.
rdar: 10734411
llvm-svn: 156550
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instruction::IsIdenticalToWhenDefined.
This manifested itself when inlining two calls to the same function. The
inlined function had a switch statement that returned one of a set of
global variables. Without this modification, the two phi instructions that
chose values from the branches of the switch instruction inlined from the
callee were considered equivalent and jump-threading replaced a load for the
first switch value with a phi selecting from the second switch, thereby
producing incorrect code.
This patch has been tested with "make check-all", "lnt runteste nt", and
llvm self-hosted, and on the original program that had this problem,
wireshark.
<rdar://problem/11025519>
llvm-svn: 156548
|
|
|
|
| |
llvm-svn: 156541
|
|
|
|
| |
llvm-svn: 156540
|
|
|
|
|
|
|
|
|
|
| |
the program.
Starting r155461 we are able to select patterns for vbroadcast even when the load op is used by other users.
Fix PR11900.
llvm-svn: 156539
|
|
|
|
|
|
| |
I initially assumed that the subreg graph was a tree. That may not be true.
llvm-svn: 156524
|
|
|
|
|
|
| |
Patch by Yury Mikhaylov <yury.mikhaylov@gmail.com>.
llvm-svn: 156523
|
|
|
|
| |
llvm-svn: 156521
|
|
|
|
|
|
| |
end of a basic block if there's no store.
llvm-svn: 156520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mapping is for internal use by TableGen. It will not be exposed in
the generated files.
Unfortunately, the mapping is not completely well-defined. The X86 xmm
registers appear with multiple sub-register indices in the ymm
registers. This is because of the odd idempotent sub_sd and sub_ss
sub-register indices. I hope to be able to eliminate them entirely, so
we can require the sub-registers to form a tree.
For now, just place the canonical sub_xmm index in the mapping, and
ignore the idempotents.
llvm-svn: 156519
|
|
|
|
|
|
| |
That's what it does.
llvm-svn: 156518
|
|
|
|
|
|
|
| |
refactor code a bit to enable future changes to support run-time information
add support to compute allocation sizes at run-time if penalty > 1 (e.g., malloc(x), calloc(x, y), and VLAs)
llvm-svn: 156515
|
|
|
|
| |
llvm-svn: 156507
|
|
|
|
|
|
| |
This bug was fixed by Jim Grosbach in #138879, thanks Jim!
llvm-svn: 156505
|
|
|
|
| |
llvm-svn: 156494
|
|
|
|
| |
llvm-svn: 156492
|
|
|
|
|
|
|
|
|
|
|
| |
For the Family 6 switch in sys::getHostCPUName, an unrecognized model was
reported as "i686". That's a really bad default since it means that new
CPUs will be treated as if they can only use 32-bit code. This just looks
at the cpuid extended feature flag for 64 bit support, and if that is set,
it uses a default x86-64 cpu. Similar logic is already used for the Family
15 code. <rdar://problem/11314502>
llvm-svn: 156486
|
|
|
|
| |
llvm-svn: 156484
|