| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 175651
|
| |
|
|
| |
llvm-svn: 175650
|
| |
|
|
| |
llvm-svn: 175648
|
| |
|
|
| |
llvm-svn: 175647
|
| |
|
|
|
|
|
| |
loads. On FreeBSD, add PROT_READ page protection flag before flushing
cache.
llvm-svn: 175646
|
| |
|
|
|
|
|
| |
Performance is the same, but LiveRangeUpdater has a more flexible
interface.
llvm-svn: 175645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding new segments to large LiveIntervals can be expensive because the
LiveRange objects after the insertion point may need to be moved left or
right. This can cause quadratic behavior when adding a large number of
segments to a live range.
The LiveRangeUpdater class allows the LIveInterval to be in a temporary
invalid state while segments are being added. It maintains an internal
gap in the LiveInterval when it is shrinking, and it has a spill area
for new segments when the LiveInterval is growing.
The behavior is similar to the existing mergeIntervalRanges() function,
except it allocates less memory for the spill area, and the algorithm is
turned inside out so the loop is driven by the clients.
llvm-svn: 175644
|
| |
|
|
|
|
| |
relocation is given with no name and an undefined section. The relocation is applied with an address of zero.
llvm-svn: 175643
|
| |
|
|
|
|
|
|
|
| |
- When extloading from a vector with non-byte-addressable element, e.g.
<4 x i1>, the current logic breaks. Extend the current logic to
fix the case where the element type is not byte-addressable by loading
all bytes, bit-extracting/packing each element.
llvm-svn: 175642
|
| |
|
|
| |
llvm-svn: 175641
|
| |
|
|
|
|
|
|
| |
The PPC backend doesn't handle these correctly. This patch uses logic
similar to that in the X86 and ARM backends to track these arguments
properly.
llvm-svn: 175635
|
| |
|
|
|
|
|
|
| |
Add HexagonMCInst class which adds various Hexagon VLIW annotations.
In addition, this class also includes some APIs related to the
constant extenders.
llvm-svn: 175634
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
During lowering of a BUILD_VECTOR, we look for opportunities to use a
vector splat. When the splatted value fits in 5 signed bits, a single
splat does the job. When it doesn't fit in 5 bits but does fit in 6,
and is an even value, we can splat on half the value and add the result
to itself.
This last optimization hasn't been working recently because of improved
constant folding. To circumvent this, create a pseudo VADD_SPLAT that
can be expanded during instruction selection.
llvm-svn: 175632
|
| |
|
|
| |
llvm-svn: 175621
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sext <4 x i1> to <4 x i64>
sext <4 x i8> to <4 x i64>
sext <4 x i16> to <4 x i64>
I'm running Combine on SIGN_EXTEND_IN_REG and revert SEXT patterns:
(sext_in_reg (v4i64 anyext (v4i32 x )), ExtraVT) -> (v4i64 sext (v4i32 sext_in_reg (v4i32 x , ExtraVT)))
The sext_in_reg (v4i32 x) may be lowered to shl+sar operations.
The "sar" does not exist on 64-bit operation, so lowering sext_in_reg (v4i64 x) has no vector solution.
I also added a cost of this operations to the AVX costs table.
llvm-svn: 175619
|
| |
|
|
| |
llvm-svn: 175617
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible that frame pointer is not found in the
callee saved info, thus FramePtrSpillFI may be incorrect
if we don't check the result of hasFP(MF).
Besides, if we enable the stack coloring algorithm, there
will be an assertion to ensure the slot is live. But in
the test case, %var1 is not live in the prologue of the
function, and we will get the assertion failure.
Note: There is similar code in ARMFrameLowering.cpp.
llvm-svn: 175616
|
| |
|
|
| |
llvm-svn: 175608
|
| |
|
|
| |
llvm-svn: 175607
|
| |
|
|
|
|
|
|
|
|
|
| |
function attributes.
This makes the LLVM assembly look better. E.g.:
define void @foo() #0 { ret void }
attributes #0 = { nounwind noinline ssp }
llvm-svn: 175605
|
| |
|
|
|
|
|
| |
common transformations. This includes updating repairIntervalsInRange() to
handle more cases.
llvm-svn: 175604
|
| |
|
|
|
|
|
| |
correct value is needed in every iteration of the loop for updating
LiveIntervals.
llvm-svn: 175603
|
| |
|
|
|
|
|
|
|
|
| |
and removing instructions. The implementation seems more complicated than it
needs to be, but I couldn't find something simpler that dealt with all of the
corner cases.
Also add a call to repairIndexesInRange() from repairIntervalsInRange().
llvm-svn: 175601
|
| |
|
|
|
|
|
| |
after the two-address pass. The remaining problems in 'make check' are occurring
later.
llvm-svn: 175598
|
| |
|
|
| |
llvm-svn: 175597
|
| |
|
|
| |
llvm-svn: 175596
|
| |
|
|
|
|
|
|
| |
SltCCRxRy16, SltiCCRxImmX16, SltiuCCRxImmX16, SltuCCRxRy16
$T8 shows up as register $24 when emitted from C++ code so we had
to change some tests that were already there for this functionality.
llvm-svn: 175593
|
| |
|
|
| |
llvm-svn: 175583
|
| |
|
|
| |
llvm-svn: 175581
|
| |
|
|
|
|
|
| |
require call cpp file anyway, so we wouldn't gain anything by keeping them
inline.
llvm-svn: 175579
|
| |
|
|
| |
llvm-svn: 175578
|
| |
|
|
|
|
| |
declarations that set the attribute groups, so we must do it on our own.
llvm-svn: 175577
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
MS-style inline assembly.
This is a follow-on to r175334. Forcing a FP to be emitted doesn't ensure it
will be used. Therefore, force the base pointer as well. We now treat MS
inline assembly in the same way we treat functions with dynamic stack
realignment and VLAs. This guarantees the BP will be used to reference
parameters and locals.
rdar://13218191
llvm-svn: 175576
|
| |
|
|
|
|
|
| |
which uses it. This is not ideal, but it ought to at least restore the
behavior to what it was before.
llvm-svn: 175571
|
| |
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (o32 abi) specific e_header setting.
EF_MIPS_ABI_O32 needs to be set in the
ELF header flags for o32 abi output.
Contributer: Reed Kotler
llvm-svn: 175569
|
| |
|
|
| |
llvm-svn: 175568
|
| |
|
|
| |
llvm-svn: 175567
|
| |
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (Mips16) specific e_header setting.
EF_MIPS_ARCH_ASE_M16 needs to be set in the
ELF header flags for Mips16.
Contributer: Reed Kotler
llvm-svn: 175566
|
| |
|
|
| |
llvm-svn: 175565
|
| |
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (MicroMips) specific STO handling .
The st_other field settig for STO_MIPS_MICROMIPS
Contributer: Zoran Jovanovic
llvm-svn: 175564
|
| |
|
|
| |
llvm-svn: 175562
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Generic STO handling at the Target level.
The st_other field of the ELF symbol table is one
byte in size. The first 2 bytes are used for generic
visibility and are currently handled by llvm.
The other six bits are processor specific and need
to be set at the target level.
A couple of notes:
The new static methods for accessing and setting the "other"
flags in include/llvm/MC/MCELF.h match the style guide
and not the other methods in the file. I don't like the
inconsistency, but feel I should follow the prescribed
lowerUpper() convention.
STO_ value definitions are not specified in gnu land as
consistently as the STT_ and STB_ fields. Probably because
the latter were defined in a standards doc and the former
defined partially in code. I have stuck with the full byte
definition of the flags.
Contributer: Zoran Jovanovic
llvm-svn: 175561
|
| |
|
|
| |
llvm-svn: 175560
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In my previous commit:
"Merge a f32 bitcast of a v2i32 extractelt
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers."
I added a pattern containing a copy_to_regclass. The copy_to_regclass is
actually not needed.
radar://13191881
llvm-svn: 175555
|
| |
|
|
|
|
|
|
| |
considered as instructions with side effects.
rdar://13227456
llvm-svn: 175553
|
| |
|
|
|
|
| |
so we cant deref it.
llvm-svn: 175550
|
| |
|
|
|
|
| |
character devices.
llvm-svn: 175549
|
| |
|
|
|
|
|
|
|
|
| |
/dev/stdin as an input when stdin is connected to a tty, for example.
No test, because it's difficult to write a reasonably portable test
for this. /dev/stdin isn't a character device when stdin is redirected
from a file or connected to a pipe.
llvm-svn: 175542
|
| |
|
|
|
|
|
|
|
| |
When creating an allocation hint for a register pair, make sure the hint
for the physical register reference is still in the allocation order.
rdar://13240556
llvm-svn: 175541
|
| |
|
|
|
|
|
|
|
|
| |
Target implementations of getRegAllocationHints() should use the
provided allocation order, and they can never return hints outside the
order. This is already documented in TargetRegisterInfo.h.
<rdar://problem/13240556>
llvm-svn: 175540
|