| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 120223
|
|
|
|
|
|
| |
Cameron Esfahani, tweaked to use array_lengthof.
llvm-svn: 114073
|
|
|
|
| |
llvm-svn: 113235
|
|
|
|
|
|
|
|
|
|
|
| |
Triple class constructor. Only valid triples should now be used
inside LLVM - front-ends are now responsable for rejecting or
correcting invalid target triples. The Triple::normalize method
can be used to straighten out funky triples provided by users.
Give this a whirl through the buildbots to see if I caught all
places where triples enter LLVM.
llvm-svn: 112470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target triple and straightens it out. This does less than gcc's script
config.sub, for example it turns i386-mingw32 into i386--mingw32 not
i386-pc-mingw32, but it does a decent job of turning funky triples into
something that the rest of the Triple class can understand. The plan
is to use this to canonicalize triple's when they are first provided
by users, and have the rest of LLVM only deal with canonical triples.
Once this is done the special case workarounds in the Triple constructor
can be removed, making the class more regular and easier to use. The
comments and unittests for the Triple class are already adjusted in this
patch appropriately for this brave new world of increased uniformity.
llvm-svn: 110909
|
|
|
|
| |
llvm-svn: 107785
|
|
|
|
| |
llvm-svn: 99392
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MicroBlaze is a highly configurable 32-bit soft-microprocessor for
use on Xilinx FPGAs. For more information see:
http://www.xilinx.com/tools/microblaze.htm
http://en.wikipedia.org/wiki/MicroBlaze
The current LLVM MicroBlaze backend generates assembly which can be
compiled using the an appropriate binutils assembler.
llvm-svn: 96969
|
|
|
|
|
|
| |
64-bit sparc codegen. Patch by Nathan Keynes!
llvm-svn: 95293
|
|
|
|
| |
llvm-svn: 89339
|
|
|
|
|
|
| |
OS and Vendor independent target assembler arch.
llvm-svn: 89122
|
|
|
|
| |
llvm-svn: 88849
|
|
|
|
| |
llvm-svn: 86251
|
|
|
|
| |
llvm-svn: 84238
|
|
|
|
|
|
|
| |
some of the inputs were temporaries. Here's a real fix for the miscompilation.
Thanks to sabre for pointing out the problem.
llvm-svn: 83417
|
|
|
|
| |
llvm-svn: 83391
|
|
|
|
| |
llvm-svn: 81393
|
|
|
|
|
|
|
|
| |
name (e.g. "ppc") to the appropriate constant.
Also, StringRefize additional Triple constructor.
llvm-svn: 81274
|
|
|
|
| |
llvm-svn: 80629
|
|
|
|
|
|
| |
identifier architecture.
llvm-svn: 79906
|
|
|
|
| |
llvm-svn: 79461
|
|
|
|
| |
llvm-svn: 79359
|
|
|
|
| |
llvm-svn: 79325
|
|
|
|
|
|
| |
- Patch by Yonggang Luo.
llvm-svn: 79315
|
|
|
|
|
|
| |
- Patch by Yonggang Luo.
llvm-svn: 79314
|
|
|
|
| |
llvm-svn: 79016
|
|
|
|
|
|
| |
in getArchTypeForLLVMName.
llvm-svn: 78799
|
|
|
|
| |
llvm-svn: 78797
|
|
|
|
|
|
|
|
| |
the darwin version string. This should help consolidate
the variety of weird functions we have scattered around the
codebase that do stuff like this.
llvm-svn: 78792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.
This has one important change in the way behavior of the JIT and llc.
For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.
For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.
The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.
llvm-svn: 77946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generate code for the Blackfin family of DSPs from Analog Devices:
http://www.analog.com/en/embedded-processing-dsp/blackfin/processors/index.html
We aim to be compatible with the exsisting GNU toolchain found at:
http://blackfin.uclinux.org/gf/project/toolchain
The back-end is experimental.
llvm-svn: 77897
|
|
|
|
| |
llvm-svn: 77125
|
|
|
|
| |
llvm-svn: 77124
|
|
|
|
|
|
| |
- This is now shorter, simpler, safer, and more efficient, what a deal.
llvm-svn: 77119
|
|
|
|
| |
llvm-svn: 75489
|
|
|
|
| |
llvm-svn: 74422
|
|
|
|
| |
llvm-svn: 73766
|
|
|
|
|
|
| |
DragonFly OS type.
llvm-svn: 72242
|
|
|
|
| |
llvm-svn: 68269
|
|
- The code is silly, I'm just amusing myself. Rewrite to be efficient
if you like. :)
Also, if you wish to debate the proper names of the triple components
I'm all ears.
llvm-svn: 68252
|