| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 234586
|
|
|
|
| |
llvm-svn: 232728
|
|
|
|
| |
llvm-svn: 232057
|
|
|
|
| |
llvm-svn: 231824
|
|
|
|
|
|
|
|
|
| |
a lookup, pass that in rather than use a naked call to getSubtargetImpl.
This involved passing down and around either a TargetMachine or
TargetRegisterInfo. Update all callers/definitions around the targets
and SelectionDAG.
llvm-svn: 230699
|
|
|
|
|
|
|
|
|
| |
This required plumbing a TargetRegisterInfo through computeRegisterProperties
and into findRepresentativeClass which uses it for register class
iteration. This required passing a subtarget into a few target specific
initializations of TargetLowering.
llvm-svn: 230583
|
|
|
|
|
|
|
|
|
|
|
| |
Everyone except R600 was manually passing the length of a static array
at each callsite, calculated in a variety of interesting ways. Far
easier to let ArrayRef handle that.
There should be no functional change, but out of tree targets may have
to tweak their calls as with these examples.
llvm-svn: 230118
|
|
|
|
| |
llvm-svn: 228614
|
|
|
|
|
|
| |
multiply to be expanded.
llvm-svn: 228347
|
|
|
|
| |
llvm-svn: 227949
|
|
|
|
| |
llvm-svn: 227871
|
|
|
|
| |
llvm-svn: 227379
|
|
|
|
| |
llvm-svn: 226288
|
|
|
|
|
|
| |
to new ones.
llvm-svn: 226179
|
|
|
|
| |
llvm-svn: 226176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type (in addition to the memory type).
The *LoadExt* legalization handling used to only have one type, the
memory type. This forced users to assume that as long as the extload
for the memory type was declared legal, and the result type was legal,
the whole extload was legal.
However, this isn't always the case. For instance, on X86, with AVX,
this is legal:
v4i32 load, zext from v4i8
but this isn't:
v4i64 load, zext from v4i8
Whereas v4i64 is (arguably) legal, even without AVX2.
Note that the same thing was done a while ago for truncstores (r46140),
but I assume no one needed it yet for extloads, so here we go.
Calls to getLoadExtAction were changed to add the value type, found
manually in the surrounding code.
Calls to setLoadExtAction were mechanically changed, by wrapping the
call in a loop, to match previous behavior. The loop iterates over
the MVT subrange corresponding to the memory type (FP vectors, etc...).
I also pulled neighboring setTruncStoreActions into some of the loops;
those shouldn't make a difference, as the additional types are illegal.
(e.g., i128->i1 truncstores on PPC.)
No functional change intended.
Differential Revision: http://reviews.llvm.org/D6532
llvm-svn: 225421
|
|
|
|
| |
llvm-svn: 223693
|
|
|
|
|
|
| |
requires TargetLoweringObjectFile to be passed.
llvm-svn: 221926
|
|
|
|
|
|
| |
TargetMachine so that different subtargets could share the TLOF effectively
llvm-svn: 221878
|
|
|
|
|
|
|
|
|
| |
to get the subtarget and that's accessible from the MachineFunction
now. This helps clear the way for smaller changes where we getting
a subtarget will require passing in a MachineFunction/Function as
well.
llvm-svn: 214988
|
|
|
|
|
|
|
|
|
|
|
| |
shorter/easier and have the DAG use that to do the same lookup. This
can be used in the future for TargetMachine based caching lookups from
the MachineFunction easily.
Update the MIPS subtarget switching machinery to update this pointer
at the same time it runs.
llvm-svn: 214838
|
|
|
|
|
|
| |
information and update all callers. No functional change.
llvm-svn: 214781
|
|
|
|
|
|
| |
but a normal TargetMachine and remove a few cached uses.
llvm-svn: 211821
|
|
|
|
| |
llvm-svn: 211820
|
|
|
|
|
|
|
|
| |
il is legal for Hexagon, so I should have marked this as Expand for
SELECT_CC when I removed setOperationAction(ISD::SELECT_CC, MVT::Other,
Expand); in r210541.
llvm-svn: 210544
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SelectionDAG bad a special case for ISD::SELECT_CC, where it would
allow targets to specify:
setOperationAction(ISD::SELECT_CC, MVT::Other, Expand);
to indicate that they wanted to expand ISD::SELECT_CC for all types.
This wasn't applied correctly everywhere, and it makes writing new
DAG patterns with ISD::SELECT_CC difficult.
llvm-svn: 210541
|
|
|
|
|
|
|
|
| |
This consolidates code from the Hexagon, R600, and XCore targets.
No functionality change intended.
llvm-svn: 210539
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
| |
llvm-svn: 207374
|
|
|
|
| |
llvm-svn: 207327
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
llvm-svn: 206822
|
|
|
|
| |
llvm-svn: 205610
|
|
|
|
| |
llvm-svn: 198585
|
|
|
|
|
|
|
|
|
| |
constant.
This moves the check up into the parent class so that all targets can use it
without having to copy (and keep in sync) the same error message.
llvm-svn: 198579
|
|
|
|
|
|
|
|
|
|
| |
constant
__builtin_returnaddress requires that the value passed into is be a constant.
However, at -O0 even a constant expression may not be converted to a constant.
Emit an error message intead of crashing.
llvm-svn: 198531
|
|
|
|
| |
llvm-svn: 193499
|
|
|
|
| |
llvm-svn: 190448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change came about primarily because of two issues in the existing code.
Niether of:
define i64 @test1(i64 %val) {
%in = trunc i64 %val to i32
tail call i32 @ret32(i32 returned %in)
ret i64 %val
}
define i64 @test2(i64 %val) {
tail call i32 @ret32(i32 returned undef)
ret i32 42
}
should be tail calls, and the function sameNoopInput is responsible. The main
problem is that it is completely symmetric in the "tail call" and "ret" value,
but in reality different things are allowed on each side.
For these cases:
1. Any truncation should lead to a larger value being generated by "tail call"
than needed by "ret".
2. Undef should only be allowed as a source for ret, not as a result of the
call.
Along the way I noticed that a mismatch between what this function treats as a
valid truncation and what the backends see can lead to invalid calls as well
(see x86-32 test case).
This patch refactors the code so that instead of being based primarily on
values which it recurses into when necessary, it starts by inspecting the type
and considers each fundamental slot that the backend will see in turn. For
example, given a pathological function that returned {{}, {{}, i32, {}}, i32}
we would consider each "real" i32 in turn, and ask if it passes through
unchanged. This is much closer to what the backend sees as a result of
ComputeValueVTs.
Aside from the bug fixes, this eliminates the recursion that's going on and, I
believe, makes the bulk of the code significantly easier to understand. The
trade-off is the nasty iterators needed to find the real types inside a
returned value.
llvm-svn: 187787
|
|
|
|
|
|
| |
size.
llvm-svn: 186274
|
|
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185625
|
|
|
|
|
|
|
| |
Revert "Simplify landing pad lowering."
Revert "Remove the EXCEPTIONADDR, EHSELECTION, and LSDAADDR ISD opcodes."
llvm-svn: 185600
|
|
|
|
|
|
| |
These exception-related opcodes are not used any longer.
llvm-svn: 185596
|
|
|
|
| |
llvm-svn: 184642
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR16146: gdb.base__call-ar-st.exp fails after
pre-RA-sched=source fixes.
Patch by Xiaoyi Guo!
This also fixes an unsupported dbg.value test case. Codegen was
previously incorrect but the test was passing by luck.
llvm-svn: 182885
|
|
|
|
|
|
|
| |
Change SelectionDAG::getXXXNode() interfaces as well as call sites of
these functions to pass in SDLoc instead of DebugLoc.
llvm-svn: 182703
|
|
|
|
| |
llvm-svn: 182390
|
|
|
|
| |
llvm-svn: 181344
|
|
|
|
|
|
| |
Missing file, HexagonSplitConst32AndConst64.cpp, from lib/Target/Hexagon/CMakeLists.txt.
llvm-svn: 181334
|
|
|
|
| |
llvm-svn: 181331
|