| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
It applies to leaf functions that are otherwise not required to have
a frame pointer.
llvm-svn: 306888
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
|
|
|
|
|
|
|
|
| |
For multiplications of 64-bit values (giving 64-bit result), detect
cases where the arguments are sign-extended 32-bit values, on a per-
operand basis. This will allow few patterns to match a wider variety
of combinations in which extensions can occur.
llvm-svn: 304223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently FPOWI defaults to Legal and LegalizeDAG.cpp turns Legal into Expand for this opcode because Legal is a "lie".
This patch changes the default for this opcode to Expand and removes the hack from LegalizeDAG.cpp. It also removes all the code in the targets that set this opcode to Expand themselves since they can just rely on the default.
Reviewers: spatel, RKSimon, efriedma
Reviewed By: RKSimon
Subscribers: jfb, dschuff, sbc100, jgravelle-google, nemanjai, javed.absar, andrew.w.kaylor, llvm-commits
Differential Revision: https://reviews.llvm.org/D33530
llvm-svn: 304215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using arguments with attribute inalloca creates problems for verification
of machine representation. This attribute instructs the backend that the
argument is prepared in stack prior to CALLSEQ_START..CALLSEQ_END
sequence (see http://llvm.org/docs/InAlloca.htm for details). Frame size
stored in CALLSEQ_START in this case does not count the size of this
argument. However CALLSEQ_END still keeps total frame size, as caller can
be responsible for cleanup of entire frame. So CALLSEQ_START and
CALLSEQ_END keep different frame size and the difference is treated by
MachineVerifier as stack error. Currently there is no way to distinguish
this case from actual errors.
This patch adds additional argument to CALLSEQ_START and its
target-specific counterparts to keep size of stack that is set up prior to
the call frame sequence. This argument allows MachineVerifier to calculate
actual frame size associated with frame setup instruction and correctly
process the case of inalloca arguments.
The changes made by the patch are:
- Frame setup instructions get the second mandatory argument. It
affects all targets that use frame pseudo instructions and touched many
files although the changes are uniform.
- Access to frame properties are implemented using special instructions
rather than calls getOperand(N).getImm(). For X86 and ARM such
replacement was made previously.
- Changes that reflect appearance of additional argument of frame setup
instruction. These involve proper instruction initialization and
methods that access instruction arguments.
- MachineVerifier retrieves frame size using method, which reports sum of
frame parts initialized inside frame instruction pair and outside it.
The patch implements approach proposed by Quentin Colombet in
https://bugs.llvm.org/show_bug.cgi?id=27481#c1.
It fixes 9 tests failed with machine verifier enabled and listed
in PR27481.
Differential Revision: https://reviews.llvm.org/D32394
llvm-svn: 302527
|
|
|
|
|
|
| |
Patch by Sid Manning.
llvm-svn: 301955
|
|
|
|
| |
llvm-svn: 300603
|
|
|
|
|
|
|
|
| |
Patch by Michael Wu.
Differential Revision: https://reviews.llvm.org/D32000
llvm-svn: 300199
|
|
|
|
|
|
|
|
|
|
| |
assertion
Patch by Michael Wu.
Differential Revision: https://reviews.llvm.org/D31999
llvm-svn: 300198
|
|
|
|
| |
llvm-svn: 296772
|
|
|
|
|
|
|
|
|
|
|
| |
On Hexagon, values of type i1 are passed in registers of type i32,
even though i1 is not a legal value for these registers. This is a
special case and needs special handling to maintain consistency of
the lowering information.
This fixes PR32089.
llvm-svn: 296645
|
|
|
|
| |
llvm-svn: 295981
|
|
|
|
| |
llvm-svn: 295892
|
|
|
|
|
|
| |
Reapply r295371 with a fix for the Windows bot failures.
llvm-svn: 295504
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r295371.
It broke windows bots:
http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/11402/steps/test-llvm/logs/stdio
llvm-svn: 295402
|
|
|
|
|
|
| |
All the cool targets are doing it...
llvm-svn: 295371
|
|
|
|
|
|
| |
other minor fixes (NFC).
llvm-svn: 290024
|
|
|
|
|
|
|
|
|
|
|
| |
For pairs of 32-bit registers: isub_lo, isub_hi.
For pairs of vector registers: vsub_lo, vsub_hi.
Add generic subreg indices: ps_sub_lo, ps_sub_hi, and a function
HexagonRegisterInfo::getHexagonSubRegIndex(RegClass, GenericSubreg)
that returns the appropriate subreg index for RegClass.
llvm-svn: 286377
|
|
|
|
| |
llvm-svn: 286049
|
|
|
|
| |
llvm-svn: 285297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
take a GlobalObject.
These functions are about classifying a global which will actually be
emitted, so it does not make sense for them to take a GlobalValue which may
for example be an alias.
Change the Mach-O object writer and the Hexagon, Lanai and MIPS backends to
look through aliases before using TargetLoweringObjectFile interfaces. These
are functional changes but all appear to be bug fixes.
Differential Revision: https://reviews.llvm.org/D25917
llvm-svn: 285006
|
|
|
|
|
|
| |
Remove the portability macro now that it is unused.
llvm-svn: 284681
|
|
|
|
| |
llvm-svn: 281495
|
|
|
|
| |
llvm-svn: 281493
|
|
|
|
|
|
|
| |
- Expand SELECT_CC and BR_CC for vector types.
- Implement TLI::isShuffleMaskLegal.
llvm-svn: 281397
|
|
|
|
|
|
| |
Recent change exposed this issue, breaking the Hexagon buildbots.
llvm-svn: 280973
|
|
|
|
| |
llvm-svn: 279303
|
|
|
|
| |
llvm-svn: 279302
|
|
|
|
|
|
|
|
| |
They can be deleted or replicated, so the cache may become outdated.
They only need to be visited once during frame lowering, so just scan
the function instead.
llvm-svn: 279297
|
|
|
|
|
|
| |
Patch by Arnold Schwaighofer.
llvm-svn: 279251
|
|
|
|
|
|
|
|
|
| |
Improved handling of fma, floating point min/max, additional load/store
instructions for floating point types.
Patch by Jyotsna Verma.
llvm-svn: 279239
|
|
|
|
|
|
|
|
|
|
| |
The names of the tablegen defs now match the names of the ISD nodes.
This makes the world a slightly saner place, as previously "fround" matched
ISD::FP_ROUND and not ISD::FROUND.
Differential Revision: https://reviews.llvm.org/D23597
llvm-svn: 279129
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ALIGNA PS_aligna
ALLOCA PS_alloca
TFR_FI PS_fi
TFR_FIA PS_fia
TFR_PdFalse PS_false
TFR_PdTrue PS_true
VMULW PS_vmulw
VMULW_ACC PS_vmulw_acc
llvm-svn: 278832
|
|
|
|
|
|
|
|
|
|
|
| |
LowerTargetConstantPool is not properly setting the TargetFlag to indicate
desired relocation. Coding error, the offset parameter was omitted, so the
TargetFlag was used as the offset, and the TargetFlag defaulted to zero.
This only affects -fpic compilation, and only those items created in a
Constant Pool, for example a vector of constants. Halide ran into this issue.
llvm-svn: 278614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- CALLv3nr PS_call_nr
- CALLRv3nr PS_callr_nr
- CALLstk PS_call_stk
- TCRETURNi PS_tailcall_i
- TCRETURNr PS_tailcall_r
- JMPret PS_jmpret
- JMPrett PS_jmprett
- JMPretf PS_jmpretf
- JMPrettnew PS_jmprettnew
- JMPretfnew PS_jmpretfnew
- JMPrettnewpt PS_jmprettnewpt
- JMPretfnewpt PS_jmpretfnewpt
llvm-svn: 278499
|
|
|
|
| |
llvm-svn: 278236
|
|
|
|
| |
llvm-svn: 278040
|
|
|
|
|
|
|
|
| |
When the same base address is used to load two different data types, LSR
would assume a memory type of "void". This type is not sized and has no
alignment information. Checking for it causes a crash.
llvm-svn: 277601
|
|
|
|
|
|
|
| |
- Implement getOptimalMemOpType.
- Check BaseOffset in isLegalAddressingMode.
llvm-svn: 277494
|
|
|
|
| |
llvm-svn: 277383
|
|
|
|
| |
llvm-svn: 277374
|
|
|
|
| |
llvm-svn: 277372
|
|
|
|
|
|
| |
Will submit another patch with the testcase only.
llvm-svn: 277180
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAG combiner tries to merge stores to adjacent vector wide memory
locations by creating stores which are integral multiples of the vector
width. Discourage this by informing it that this is slow. This should
not affect legalization passes, because all of them ignore the "Fast"
argument.
Patch by Pranav Bhandarkar.
llvm-svn: 277178
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the mask of a vector shuffle has alternating odd or even numbers
starting with 1 or 0 respectively up to the largest possible index
for the given type in the given HVX mode (single of double) we can
generate vpacko or vpacke instruction respectively.
E.g.
%42 = shufflevector <32 x i16> %37, <32 x i16> %41,
<32 x i32> <i32 1, i32 3, ..., i32 63>
is %42.h = vpacko(%41.w, %37.w)
Patch by Pranav Bhandarkar.
llvm-svn: 277168
|
|
|
|
|
|
|
| |
getFrameInfo() never returns nullptr so we should use a reference
instead of a pointer.
llvm-svn: 277017
|
|
|
|
|
|
|
| |
- Generate vector post-increment stores more aggressively.
- Predicate post-increment and vector stores in early if-conversion.
llvm-svn: 276800
|
|
|
|
| |
llvm-svn: 276638
|
|
|
|
|
|
|
| |
This is not compliant with the official ABI, but allows experimentation
with calling conventions.
llvm-svn: 275825
|
|
|
|
| |
llvm-svn: 275824
|