| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
* Align targets of indirect jumps to instruction bundle boundaries (in MI layer).
* Add masking instructions before indirect jumps (in MC layer).
Differential Revision: http://llvm-reviews.chandlerc.com/D2847
llvm-svn: 202479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This should fix the MCJIT unit tests that were broken by r201792 on the MIPS buildbot.
MIPS currently uses the default implementation of sys::getHostCPUName() which
always returns "generic". For now, we will accept "generic" and coerce it to
"mips32" or "mips64" depending on the target architecture like we do for empty
CPU names.
Reviewers: jacksprat, matheusalmeida
Reviewed By: jacksprat
Differential Revision: http://llvm-reviews.chandlerc.com/D2878
llvm-svn: 202253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is consistent with the integrated assembler.
All mips64 codegen tests previously passed -mcpu. Removed -mcpu from
blez_bgez.ll and const-mult.ll to cover the default case.
Ideally, the two implementations of selectMipsCPU() will be merged but it's
proven difficult to find a home for the function that doesn't cause link errors.
For now, we'll hoist the common functionality into a function and mark it with
FIXME's.
Reviewers: jacksprat, matheusalmeida
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D2830
llvm-svn: 201782
|
|
|
|
|
|
|
|
|
|
| |
changing the CPU value.
This is consistent with the way CodeGen acheives this. However, CodeGen
always selects mips32 (even when the architecture is mips64).
llvm-svn: 201694
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 201689
|
|
|
|
|
|
| |
Clang itself was not using this. The only way to access it was via llc.
llvm-svn: 200862
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were:
* noreorder handling on the target object streamer and asm parser.
* setting the initial flag bits based on the enabled features.
* setting the elf header flag for micromips
It is *really* depressing I am the one doing this instead of someone at
mips actually taking the time to understand the infrastructure.
llvm-svn: 200138
|
|
|
|
|
|
|
| |
With this the target streamers will be able to know the target features that
are in use.
llvm-svn: 200135
|
|
|
|
|
|
|
|
|
|
| |
This has a few advantages:
* Only targets that use a MCTargetStreamer have to worry about it.
* There is never a MCTargetStreamer without a MCStreamer, so we can use a
reference.
* A MCTargetStreamer can talk to the MCStreamer in its constructor.
llvm-svn: 200129
|
|
|
|
|
|
|
|
|
|
| |
This patch adds .abicalls and .set pic0 support which
affects the ELF ABI and its flags. In addition the patch uses
a common interface for both the MipsTargetSteamer and
MipsObjectStreamer that both the integrated and standalone
assemblers will use for the output for these directives.
llvm-svn: 198646
|
|
|
|
| |
llvm-svn: 195152
|
|
|
|
| |
llvm-svn: 195076
|
|
|
|
|
|
| |
No functionality changes.
llvm-svn: 195057
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes an old FIXME by creating a MCTargetStreamer interface
and moving the target specific functions for ARM, Mips and PPC to it.
The ARM streamer is still declared in a common place because it is
used from lib/CodeGen/ARMException.cpp, but the Mips and PPC are
completely hidden in the corresponding Target directories.
I will send an email to llvmdev with instructions on how to use this.
llvm-svn: 192181
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When MC was first added, targets could use hasRawTextSupport to keep features
working before they were added to the MC interface.
The design goal of MC is to provide an uniform api for printing assembly and
object files. Short of relaxations and other corner cases, a object file is
just another representation of the assembly.
It was never the intention that targets would keep doing things like
if (hasRawTextSupport())
Set flags in one way.
else
Set flags in another way.
When they do that they create two code paths and the object file is no longer
just another representation of the assembly. This also then requires testing
with llc -filetype=obj, which is extremelly brittle.
This patch removes some of these hacks by replacing them with smaller ones.
The ARM flag setting is trivial, so I just moved it to the constructor. For
Mips, the patch adds two temporary hack directives that allow the assembly
to represent the same things as the object file was already able to.
The hope is that the mips developers will replace the hack directives with
the same ones that gas uses and drop the -print-hack-directives flag.
I will also try to implement a target streamer interface, so that we can
move this out of the common code.
In summary, for any new work, two rules of the thumb are
* Don't use "llc -filetype=obj" in tests.
* Don't add calls to hasRawTextSupport.
llvm-svn: 192035
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was just a less powerful and more confusing version of
MCCFIInstruction. A side effect is that, since MCCFIInstruction uses
dwarf register numbers, calls to getDwarfRegNum are pushed out, which
should allow further simplifications.
I left the MachineModuleInfo::addFrameMove interface unchanged since
this patch was already fairly big.
llvm-svn: 181680
|
|
|
|
| |
llvm-svn: 181618
|
|
|
|
|
|
|
|
| |
setting of ELF header e_flags.
Contributer: Jack Carter
llvm-svn: 173884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
|
|
| |
Patch by Vladimir Medic.
llvm-svn: 154935
|
|
|
|
| |
llvm-svn: 153925
|
|
|
|
|
|
| |
Patch by Vladimir Medic.
llvm-svn: 153924
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows llvm to recognize that a 64 bit object file is being produced
and that the subsequently generated ELF header has the correct information.
The test case checks for both big and little endian flavors.
Patch by Jack Carter.
llvm-svn: 153889
|
|
|
|
|
|
| |
getInstructionName and the static data it contains since the same tables are already in MCInstrInfo.
llvm-svn: 153860
|
|
|
|
| |
llvm-svn: 153795
|
|
|
|
|
|
|
| |
Used to allow context sensitive printing of super-register or sub-register
references.
llvm-svn: 152043
|
|
|
|
|
|
|
|
| |
objects for big endian and little endian targets.
Patch by Jack Carter.
llvm-svn: 151788
|
|
|
|
| |
llvm-svn: 150805
|
|
|
|
| |
llvm-svn: 149814
|
|
|
|
| |
llvm-svn: 147924
|
|
|
|
| |
llvm-svn: 146896
|
|
|
|
|
|
|
| |
and code model. This eliminates the need to pass OptLevel flag all over the
place and makes it possible for any codegen pass to use this information.
llvm-svn: 144788
|
|
|
|
|
|
|
|
|
|
| |
"With this patch we can now generate runnable Mips code through LLVM
direct object emission. We have run numerous simple programs, both C
and C++ and with -O0 and -O3 from the output. The code is not production
ready, but quite useful for experimentation." Patch and message by
Jack Carter
llvm-svn: 144414
|
|
|
|
|
|
| |
Patch by Reed Kotler at Mips Technologies.
llvm-svn: 140887
|
|
|
|
|
|
| |
Patch by Reed Kotler at Mips Technologies.
llvm-svn: 140886
|
|
|
|
|
|
| |
Patch by Reed Kotler at Mips Technologies.
llvm-svn: 140878
|
|
|
|
| |
llvm-svn: 140233
|
|
|
|
| |
llvm-svn: 139622
|
|
|
|
| |
llvm-svn: 139607
|
|
|
|
|
|
| |
handling to llvm-mc. Reviewed by Owen Anderson.
llvm-svn: 139237
|
|
|
|
|
|
| |
These are strictly utilities for registering targets and components.
llvm-svn: 138450
|
|
|
|
|
|
| |
from MC.
llvm-svn: 138367
|
|
|
|
| |
llvm-svn: 135974
|
|
|
|
| |
llvm-svn: 135826
|
|
|
|
|
|
| |
InitializeX86MCInstrInfo, etc. are combined into InitializeX86TargetMC.
llvm-svn: 135812
|
|
|
|
|
|
|
|
| |
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
llvm-svn: 135580
|
|
|
|
|
|
|
| |
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
llvm-svn: 135468
|
|
|
|
|
|
| |
better location welcome).
llvm-svn: 135438
|