| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 316804
|
|
|
|
|
|
|
| |
Making sure that an instruction has fewer operands than required, then
attempting to access one out of range is going to fail.
llvm-svn: 316785
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In getOffsetRange, Max can be set to 0 to force the extender replacement
to be at or below the original value. This would cause the new offset to
be non-negative, which is preferred for memory instructions (to reduce
the likelihood of it getting constant-extended due to predication). The
problem happens when the range is shifted by an offset (present in the
instruction being examined) and the offset is negative. The entire range
for the allowable deviation will then be strictly negative. This creates
a problem, since 0 is assumed to be a valid deviation.
llvm-svn: 316601
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the MIRPrinter to include the regclass when printing
virtual register defs, which is already valid syntax for the
parser. That is, given 64 bit %0 and %1 in a "gpr" regbank,
%1(s64) = COPY %0(s64)
would now be written as
%1:gpr(s64) = COPY %0(s64)
While this change alone introduces a bit of redundancy with the
registers block, it allows us to update the tests to be more concise
and understandable and brings us closer to being able to remove the
registers block completely.
Note: We generally only print the class in defs, but there is one
exception. If there are uses without any defs whatsoever, we'll print
the class on all uses. I'm not completely convinced this comes up in
meaningful machine IR, but for now the MIRParser and MachineVerifier
both accept that kind of stuff, so we don't want to have a situation
where we can print something we can't parse.
llvm-svn: 316479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In HexagonISelLowering, there is code to handle the case when
a function returns an i1 type. In this case, we need to generate
extra nodes to copy the result from R0 to a predicate register.
The code was returning the wrong value for the chain edge which
caused an assert "Wrong topological sorting" when converting the
instructions to MIs.
This patch fixes the problem by returning the chain for the final
copy.
Patch by Brendon Cahoon.
llvm-svn: 316367
|
|
|
|
|
|
| |
One combination was missing: add(add(x,y),c).
llvm-svn: 316363
|
|
|
|
| |
llvm-svn: 316243
|
|
|
|
| |
llvm-svn: 316236
|
|
|
|
| |
llvm-svn: 316228
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).
llvm-svn: 316218
|
|
|
|
| |
llvm-svn: 316170
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch lets the llvm tools handle the new HVX target features that
are added by frontend (clang). The target-features are of the form
"hvx-length64b" for 64 Byte HVX mode, "hvx-length128b" for 128 Byte mode HVX.
"hvx-double" is an alias to "hvx-length128b" and is soon will be deprecated.
The hvx version target feature is upgated form "+hvx" to "+hvxv{version_number}.
Eg: "+hvxv62"
For the correct HVX code generation, the user must use the following
target features.
For 64B mode: "+hvxv62" "+hvx-length64b"
For 128B mode: "+hvxv62" "+hvx-length128b"
Clang picks a default length if none is specified. If for some reason,
no hvx-length is specified to llvm, the compilation will bail out.
There is a corresponding clang patch.
Differential Revision: https://reviews.llvm.org/D38851
llvm-svn: 316101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Each constant extender requires an extra instruction, which adds to the
code size and also reduces the number of available slots in an instruction
packet. In most cases, the value of a repeated constant extender could be
loaded into a register, and the instructions using the extender could be
replaced with their counterparts that use that register instead.
This patch adds a pass that tries to reduce the number of constant
extenders, including extenders which differ only in an immediate offset
known at compile time, e.g. @global and @global+12.
llvm-svn: 315735
|
|
|
|
|
|
| |
Patch by Sumanth Gundapaneni.
llvm-svn: 315692
|
|
|
|
| |
llvm-svn: 315510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pipeliner is generating a serial sequence that causes poor
register allocation when a post-increment instruction appears
prior to the use of the post-increment register. This occurs when
there is a circular set of dependences involved with a sequence
of instructions in the same cycle. In this case, there is no
serialization of the parallel semantics that will not cause an
additional register to be allocated.
This patch fixes the problem by changing the instructions so that
the post-increment instruction is used by the subsequent
instruction, which enables the register allocator to make a
better decision and not require another register.
Patch by Brendon Cahoon.
llvm-svn: 315466
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
HexagonVectorLoopCarriedReuse pass
If the two instructions being compared for equivalence have corresponding operands
that are integer constants, then check their values to determine equivalence.
Patch by Suyog Sarda!
llvm-svn: 314642
|
|
|
|
|
|
|
| |
This patch extracts 1 element from vector consisting
of elements of size 1 bit at given index.
llvm-svn: 314641
|
|
|
|
|
|
| |
This patch produces a crash and hexagon_vector_loop_carried_reuse_constant.ll test fails on Windows (llvm-clang-x86_64-expensive-checks-win build bot).
llvm-svn: 314361
|
|
|
|
|
|
|
|
|
| |
If the two instructions being compared for equivalence have corresponding operands
that are integer constants, then check their values to determine equivalence.
Patch by Suyog Sarda!
llvm-svn: 313993
|
|
|
|
| |
llvm-svn: 313936
|
|
|
|
|
|
|
|
|
|
| |
HexagonVectorLoopCarriedReuse pass"
This reverts commit r313926.
It was failing in some bots.
llvm-svn: 313931
|
|
|
|
|
|
| |
added HexagonVectorLoopCarriedReuse pass
llvm-svn: 313926
|
|
|
|
|
|
|
|
| |
Patch by Jesper Antonsson.
Differential Revision: https://reviews.llvm.org/D37611
llvm-svn: 313268
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D37600
llvm-svn: 312797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tail merging can convert an undef use into a normal one when creating a
common tail. Doing so can make the register live out from a block which
previously contained the undef use. To keep the liveness up-to-date,
insert IMPLICIT_DEFs in such blocks when necessary.
To enable this patch the computeLiveIns() function which used to
compute live-ins for a block and set them immediately is split into new
functions:
- computeLiveIns() just computes the live-ins in a LivePhysRegs set.
- addLiveIns() applies the live-ins to a block live-in list.
- computeAndAddLiveIns() is a convenience function combining the other
two functions and behaving like computeLiveIns() before this patch.
Based on a patch by Krzysztof Parzyszek <kparzysz@codeaurora.org>
Differential Revision: https://reviews.llvm.org/D37034
llvm-svn: 312668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When if-converting a diamond, two separate blocks will be placed back
to back to form a straight line code. To ensure correctness of the
liveness information, any registers that are live in the second block
should not be killed in the first block, even if they were in the
original code.
Additionally, when the two blocks share common instructions at the
beginning, these instructions will not be duplicated, but only placed
once, before both of the blocks. Since the function "isIdenticalTo"
(as used here) ignores kill flags, the common initial code in one
block may have a kill flag for a register that is live in the other
block.
Because the code that removes kill flags only runs for the non-common
parts of the predicated blocks, a kill flag mismatch in the common
code could still lead to a live register being killed prematurely.
llvm-svn: 312654
|
|
|
|
| |
llvm-svn: 312644
|
|
|
|
|
|
|
| |
Insert artificial edges between loads that could cause a cache bank
conflict.
llvm-svn: 311901
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The check (assuming positive stride) for validity of memmove should be
(a) the destination is at a lower address than the source, or
(b) the distance between the source and destination is greater than or
equal the number of bytes copied.
For the second part it is sufficient to assume that the destination
is at a higher address, since the opposite case is covered by (a).
The distance calculation was previously done by subtracting the
pointers in the wrong order.
llvm-svn: 311650
|
|
|
|
| |
llvm-svn: 310524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isLegalAddressingMode() has recently gained the extra optional Instruction*
parameter, and therefore it can now do the job that previously only
isFoldableMemAccess() could do.
The SystemZ implementation of isLegalAddressingMode() has gained the
functionality of checking for offsets, which used to be done with
isFoldableMemAccess().
The isFoldableMemAccess() hook has been removed everywhere.
Review: Quentin Colombet, Ulrich Weigand
https://reviews.llvm.org/D35933
llvm-svn: 310463
|
|
|
|
|
|
|
|
|
| |
Certain operations require vector of i1 values. However, for Hexagon
architecture compatibility, they need to be represented as vector of i8.
Patch by Suyog Sarda.
llvm-svn: 309677
|
|
|
|
| |
llvm-svn: 308914
|
|
|
|
|
|
|
| |
For example
asm ("memw(%0++%1) = %2" : : "r"(addr),"a"(mod),"r"(val) : "memory")
llvm-svn: 308761
|
|
|
|
| |
llvm-svn: 308510
|
|
|
|
|
|
|
|
| |
The flag "-hexagon-emit-lut-text" (defaulted to false) is added to decide
on where to keep the switch generated lookup table.
Differential Revision: https://reviews.llvm.org/D34818
llvm-svn: 308316
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, oren_ben_simhon, niravd, mcrosier
Reviewed By: oren_ben_simhon, mcrosier
Subscribers: nhaehnle, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D35466
llvm-svn: 308193
|
|
|
|
|
|
|
| |
The target-independent lowering works fine, except concatenating 32-bit
words. Add a pattern to generate A2_combinew instead of 64-bit asl/or.
llvm-svn: 308186
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the LLVM part, adding definitions for
void @llvm.hexagon.Y2.dccleana(i8*)
void @llvm.hexagon.Y2.dccleaninva(i8*)
void @llvm.hexagon.Y2.dcinva(i8*)
void @llvm.hexagon.Y2.dczeroa(i8*)
void @llvm.hexagon.Y4.l2fetch(i8*, i32)
void @llvm.hexagon.Y5.l2fetch(i8*, i64)
The clang part will follow.
llvm-svn: 308032
|
|
|
|
| |
llvm-svn: 307675
|
|
|
|
|
|
|
|
| |
Patch by Michael Wu.
Differential Revision: https://reviews.llvm.org/D35104
llvm-svn: 307671
|
|
|
|
|
|
| |
This fixes https://llvm.org/PR33718.
llvm-svn: 307566
|
|
|
|
| |
llvm-svn: 307153
|
|
|
|
|
|
|
| |
It applies to leaf functions that are otherwise not required to have
a frame pointer.
llvm-svn: 306888
|
|
|
|
|
|
|
|
| |
This patch adds a new LLVM flag -hexagon-emit-jt-text which is defaulted to
"false". The value "true" emits the switch generated jump tables in text section.
Differential Revision: https://reviews.llvm.org/D34820
llvm-svn: 306872
|
|
|
|
|
|
|
| |
This reverts commit ae521f4192c3ed0202c047fec993cb59133dd1a0.
Wrong commit message
llvm-svn: 306871
|
|
|
|
|
|
|
|
|
| |
The llvm flag "-hexagon-emit-lookup-tables" guards the generation
of lookup table from a switch statement.
Differential Revision: https://reviews.llvm.org/D34819
llvm-svn: 306869
|
|
|
|
|
|
|
| |
The dead phis are needed for finding correct would-be reaching defs
in register propagation.
llvm-svn: 306690
|
|
|
|
| |
llvm-svn: 306553
|