Commit Graph

76 Commits

Author SHA1 Message Date
NAKAMURA Takumi aaf66c7357 Target/*/CMakeLists.txt: Add the dependency to CommonTableGen explicitly for each corresponding CodeGen.
Without explicit dependencies, both per-file action and in-CommonTableGen action could run in parallel.
It races to emit *.inc files simultaneously.

llvm-svn: 187780
2013-08-06 06:38:37 +00:00
Silviu Baranga 82dd6ac3bc Adding an A15 specific optimization pass for interactions between S/D/Q registers. The pass handles all the required transformations pre-regalloc.
llvm-svn: 177169
2013-03-15 18:28:25 +00:00
Chandler Carruth 664e354de7 Switch TargetTransformInfo from an immutable analysis pass that requires
a TargetMachine to construct (and thus isn't always available), to an
analysis group that supports layered implementations much like
AliasAnalysis does. This is a pretty massive change, with a few parts
that I was unable to easily separate (sorry), so I'll walk through it.

The first step of this conversion was to make TargetTransformInfo an
analysis group, and to sink the nonce implementations in
ScalarTargetTransformInfo and VectorTargetTranformInfo into
a NoTargetTransformInfo pass. This allows other passes to add a hard
requirement on TTI, and assume they will always get at least on
implementation.

The TargetTransformInfo analysis group leverages the delegation chaining
trick that AliasAnalysis uses, where the base class for the analysis
group delegates to the previous analysis *pass*, allowing all but tho
NoFoo analysis passes to only implement the parts of the interfaces they
support. It also introduces a new trick where each pass in the group
retains a pointer to the top-most pass that has been initialized. This
allows passes to implement one API in terms of another API and benefit
when some other pass above them in the stack has more precise results
for the second API.

The second step of this conversion is to create a pass that implements
the TargetTransformInfo analysis using the target-independent
abstractions in the code generator. This replaces the
ScalarTargetTransformImpl and VectorTargetTransformImpl classes in
lib/Target with a single pass in lib/CodeGen called
BasicTargetTransformInfo. This class actually provides most of the TTI
functionality, basing it upon the TargetLowering abstraction and other
information in the target independent code generator.

The third step of the conversion adds support to all TargetMachines to
register custom analysis passes. This allows building those passes with
access to TargetLowering or other target-specific classes, and it also
allows each target to customize the set of analysis passes desired in
the pass manager. The baseline LLVMTargetMachine implements this
interface to add the BasicTTI pass to the pass manager, and all of the
tools that want to support target-aware TTI passes call this routine on
whatever target machine they end up with to add the appropriate passes.

The fourth step of the conversion created target-specific TTI analysis
passes for the X86 and ARM backends. These passes contain the custom
logic that was previously in their extensions of the
ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces.
I separated them into their own file, as now all of the interface bits
are private and they just expose a function to create the pass itself.
Then I extended these target machines to set up a custom set of analysis
passes, first adding BasicTTI as a fallback, and then adding their
customized TTI implementations.

The fourth step required logic that was shared between the target
independent layer and the specific targets to move to a different
interface, as they no longer derive from each other. As a consequence,
a helper functions were added to TargetLowering representing the common
logic needed both in the target implementation and the codegen
implementation of the TTI pass. While technically this is the only
change that could have been committed separately, it would have been
a nightmare to extract.

The final step of the conversion was just to delete all the old
boilerplate. This got rid of the ScalarTargetTransformInfo and
VectorTargetTransformInfo classes, all of the support in all of the
targets for producing instances of them, and all of the support in the
tools for manually constructing a pass based around them.

Now that TTI is a relatively normal analysis group, two things become
straightforward. First, we can sink it into lib/Analysis which is a more
natural layer for it to live. Second, clients of this interface can
depend on it *always* being available which will simplify their code and
behavior. These (and other) simplifications will follow in subsequent
commits, this one is clearly big enough.

Finally, I'm very aware that much of the comments and documentation
needs to be updated. As soon as I had this working, and plausibly well
commented, I wanted to get it committed and in front of the build bots.
I'll be doing a few passes over documentation later if it sticks.

Commits to update DragonEgg and Clang will be made presently.

llvm-svn: 171681
2013-01-07 01:37:14 +00:00
Roman Divacky e3d323052f Remove edis - the enhanced disassembler. Fixes PR14654.
llvm-svn: 170578
2012-12-19 19:55:47 +00:00
Rafael Espindola d957cb2584 Remove TargetELFWriterInfo.
All the credit goes to Jan Voung for noticing it was dead!

llvm-svn: 166902
2012-10-28 21:34:43 +00:00
NAKAMURA Takumi 704de074b8 llvm/lib: [CMake] Add explicit dependency to intrinsics_gen.
llvm-svn: 159112
2012-06-24 13:32:01 +00:00
Chandler Carruth e805b16e3d Fix up the CMake build for the new files added in r146960, they're
likely to stay either way that discussion ends up resolving itself.

llvm-svn: 146966
2011-12-20 08:42:11 +00:00
Daniel Dunbar 539d0a8a09 build/CMake: Finish removal of add_llvm_library_dependencies.
llvm-svn: 145420
2011-11-29 19:25:30 +00:00
NAKAMURA Takumi b345060a85 lib/Target/ARM/CMakeLists.txt: Disable optimization in ARMISelLowering.cpp also on MSC15(aka VS9). Seems miscompiled.
llvm-svn: 144794
2011-11-16 09:18:28 +00:00
Daniel Dunbar 4a9c6426ff build/cmake: Use tblgen macro directly instead of llvm_tablegen, which just
added a layer of indirection with no value (not even conciseness).

llvm-svn: 143727
2011-11-04 19:04:23 +00:00
Michael J. Spencer 0050f59665 Fix CMake build.
llvm-svn: 142204
2011-10-17 17:50:39 +00:00
Peter Collingbourne fb3d935649 Build system infrastructure for multiple tblgens.
llvm-svn: 141266
2011-10-06 01:51:51 +00:00
NAKAMURA Takumi 15b3c9c684 Target/ARM: Unbreak! CMake! Build!
llvm-svn: 140774
2011-09-29 03:32:49 +00:00
Jakob Stoklund Olesen bf64024a39 Delete NEONMoveFix, now unused.
llvm-svn: 140773
2011-09-29 02:56:45 +00:00
Ted Kremenek e3e36f80f5 Unbreak CMake build.
llvm-svn: 140655
2011-09-27 23:29:59 +00:00
Owen Anderson d770f6c110 Don't generate the old-style disassembler in CMake builds either.
llvm-svn: 137153
2011-08-09 21:36:11 +00:00
Owen Anderson c7afd84322 Attempt to fix CMake build.
llvm-svn: 137147
2011-08-09 21:09:59 +00:00
Chandler Carruth 9d7feab3e0 Rewrite the CMake build to use explicit dependencies between libraries,
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.

I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.

This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.

This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.

Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.

This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.

llvm-svn: 136433
2011-07-29 00:14:25 +00:00
Chandler Carruth 97c069c1d2 Clean up a pile of hacks in our CMake build relating to TableGen.
The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.

These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.

To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.

This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.

Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.

llvm-svn: 136023
2011-07-26 00:09:08 +00:00
Evan Cheng ad5f485957 Sink ARM mc routines into MCTargetDesc.
llvm-svn: 135825
2011-07-23 00:00:19 +00:00
Evan Cheng a20cde31e7 Sink ARMMCExpr and ARMAddressingModes into MC layer. First step to separate ARM MC code from target.
llvm-svn: 135636
2011-07-20 23:34:39 +00:00
Chandler Carruth 9a0001aedb Major update to CMake build to reflect changes in r135219 in the
backend. Moved some MCAsmInfo files down into the MCTargetDesc
sublibraries, removed some (i suspect long) dead files from other parts
of the CMake build, etc. Also copied the include directory hack from the
Makefile.

Finally, updated the lib deps. I spot checked this, and think its
correct, but review appreciated there.

llvm-svn: 135234
2011-07-15 00:40:52 +00:00
Chandler Carruth f21cebf6dd Add CMake support for the new TableGen file introduced in r134705.
llvm-svn: 134707
2011-07-08 17:54:08 +00:00
Oscar Fuentes 32a45e5aeb Update CMake library dependencies
llvm-svn: 134616
2011-07-07 16:33:00 +00:00
Douglas Gregor cc4a55f6f2 Fix CMake build
llvm-svn: 134614
2011-07-07 15:59:22 +00:00
Evan Cheng 928ce72bcd Add ARM MC registry routines.
llvm-svn: 134547
2011-07-06 22:02:34 +00:00
Evan Cheng c9c090d7a5 Rename XXXGenSubtarget.inc to XXXGenSubtargetInfo.inc for consistency.
llvm-svn: 134281
2011-07-01 22:36:09 +00:00
Evan Cheng 1e210d08d8 Merge XXXGenRegisterNames.inc into XXXGenRegisterInfo.inc
llvm-svn: 134024
2011-06-28 20:07:07 +00:00
Evan Cheng d9997acd14 Merge XXXGenRegisterDesc.inc XXXGenRegisterNames.inc XXXGenRegisterInfo.h.inc
into XXXGenRegisterInfo.inc.

llvm-svn: 133922
2011-06-27 18:32:37 +00:00
Evan Cheng 247533179a Starting to refactor Target to separate out code that's needed to fully describe
target machine from those that are only needed by codegen. The goal is to
sink the essential target description into MC layer so we can start building
MC based tools without needing to link in the entire codegen.

First step is to refactor TargetRegisterInfo. This patch added a base class
MCRegisterInfo which TargetRegisterInfo is derived from. Changed TableGen to
separate register description from the rest of the stuff.

llvm-svn: 133782
2011-06-24 01:44:41 +00:00
Jim Grosbach 2354f87a9d Move ARMMachObjectWriter to its own file.
Just tidy up a bit. No functional change.

llvm-svn: 133638
2011-06-22 20:14:52 +00:00
Oscar Fuentes ba1186c23e Use explicit add_subdirectory's for LLVM target sublibraries instead
of testing for its presence at cmake time.

This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.

llvm-svn: 126068
2011-02-20 02:55:27 +00:00
Evan Cheng 965b3c7323 Model :upper16: and :lower16: as ARM specific MCTargetExpr. This is a step
in the right direction. It eliminated some hacks and will unblock codegen
work. But it's far from being done. It doesn't reject illegal expressions,
e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all.

llvm-svn: 123369
2011-01-13 07:58:56 +00:00
Anton Korobeynikov 441ae5b88c Update CMake stuff
llvm-svn: 123171
2011-01-10 12:39:23 +00:00
NAKAMURA Takumi de8fda8908 CMake: Add disabling optimization on MSVC8 and MSVC10 as workaround for some files in Target/ARM and Target/X86.
llvm-svn: 122623
2010-12-29 03:59:27 +00:00
NAKAMURA Takumi 70fbbf534b ARM/CMakeLists.txt: Add missing MLxExpansionPass.cpp since r120960.
llvm-svn: 120966
2010-12-05 23:08:57 +00:00
Evan Cheng 62c7b5bf76 Making use of VFP / NEON floating point multiply-accumulate / subtraction is
difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
   of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
   additional pipeline stall. So it's frequently better to single codegen
   vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
   stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
   vmla + vmla is very bad. But this isn't ideal either:
     vmul
     vadd
     vmla
   Instead, we want to expand the second vmla:
     vmla
     vmul
     vadd
   Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
   faster.

Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.

A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
   compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
   fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
   vmla / vmls will trigger one of the special hazards.

Work in progress, only A+B are enabled.

llvm-svn: 120960
2010-12-05 22:04:16 +00:00
Anton Korobeynikov 51d2e9ca29 Attempt to unbreak cmake-based builds
llvm-svn: 119098
2010-11-15 00:48:12 +00:00
Jim Grosbach 2eed7a1310 Teach ARM Target to use the tblgen support for generating an MC'ized
CodeEmitter.

llvm-svn: 118209
2010-11-03 23:52:49 +00:00
Oscar Fuentes 5816ccd4b5 Remove explicit dependency of LLVMARMCodeGen on LLVMARMAsmPrinter. It
creates a cyclic dependency that breaks the build when
BUILD_SHARED_LIBS=ON

llvm-svn: 116480
2010-10-14 15:54:46 +00:00
Jim Grosbach 05ed521a88 grammar
llvm-svn: 115314
2010-10-01 14:57:48 +00:00
Jason W Kim b32124545b I added a new file ARMAsmBackend which stubs out in similar ways to
the eqv X86 class.
For now, I split the ELFARMAsmBackend from the DarwinARMAsmBackend
(also mimicking X86)

Tested against -r115126

llvm-svn: 115129
2010-09-30 02:17:26 +00:00
Oscar Fuentes b4b12535e8 Removed a bunch of unnecessary target_link_libraries.
llvm-svn: 114999
2010-09-28 22:39:14 +00:00
Oscar Fuentes 3da4255d07 Add ARM Disassembler to the CMake build.
llvm-svn: 114949
2010-09-28 11:48:19 +00:00
Rafael Espindola 69aa15155f Odd additional stub framework for the ARM MC ELF emission.
llc now recognizes the "intent" to support MC/obj emission for ARM, but
given that they are all stubs, it asserts on --filetype=obj --march=arm

Patch by Jason Kim.

llvm-svn: 114856
2010-09-27 18:31:37 +00:00
Jim Grosbach 1287f4f3b8 Add skeleton infrastructure for the ARMMCCodeEmitter class. Patch by Jason Kim!
llvm-svn: 114195
2010-09-17 18:46:17 +00:00
Michael J. Spencer 93c9b2ea93 Revert "CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally."
This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819
2010-09-13 23:59:48 +00:00
Bob Wilson c597fd3b4a Convert some VTBL and VTBX instructions to use pseudo instructions prior to
register allocation.  Remove the NEONPreAllocPass, which is no longer needed.
Yeah!!

llvm-svn: 113818
2010-09-13 23:55:10 +00:00
Michael J. Spencer dc38d36ccb CMake: Get rid of LLVMLibDeps.cmake and export the libraries normally.
llvm-svn: 113632
2010-09-10 21:14:25 +00:00
Daniel Dunbar 56e77c409b MC/ARM: Enable generation of the ARM asm matcher, not that it can do much.
llvm-svn: 110782
2010-08-11 05:09:20 +00:00