about summary refs log tree commit diff
path: root/src/rustllvm
AgeCommit message (Collapse)AuthorLines
2013-08-20auto merge of #8328 : alexcrichton/rust/llvm-head, r=brsonbors-4/+9
The first commit message is pretty good, but whomever reviews this should probably also at least glance at the changes I made in LLVM. I basically reorganized our pending patch queue to be a bit more organized and clearer in what needs to go where. After this, our queue would be: * Add the `no-split-stack` attribute * Add the `fixedstacksegment` attribute * Add split-stacks for arm android * Add split-stacks for arm linux * Add split stacks for mips Then there's a patch which I added to get rust to build at all on LLVM-head, and I'm not quite sure why it's there, but nothing seems to be crashing for now! (famous last words). Otherwise, I just updated code to reflect the changes I made in LLVM with the only major change being the advent of the new `no_split_stack` attribute. This is work towards #1226, but someone more familiar with the code should probably actually assign the attribute to the appropriate functions. Also as a bonus, I've verified that this closes #5774
2013-08-20Fix LLVM compilation issues and use the new attrsAlex Crichton-3/+8
This implements #[no_split_stack] and also changes #[fast_ffi] to using the new "fixedstacksegment" string attribute instead of integer attribute.
2013-08-20Upgrade llvm to current HEADAlex Crichton-1/+1
* This has one workaround patch (everything's testing just fine...) * I reworked the fixedstacksegment attribute to be specified with a string rather than using a keyword and an integer and modifying the parser * I added a "no-split-stack" attribute along the same lines as the "fixedstacksegment" attribute for #1226
2013-08-16debuginfo: Generate template type parameters for generic functions.Michael Woerister-0/+19
Conflicts: src/librustc/lib/llvm.rs src/librustc/middle/trans/debuginfo.rs src/rustllvm/RustWrapper.cpp src/rustllvm/rustllvm.def.in
2013-08-11auto merge of #8410 : luqmana/rust/mcpu, r=sanxiynbors-1/+2
Adds `--target-cpu` flag which lets you choose a more specific target cpu instead of just passing the default, `generic`. It's more or less akin to `-mcpu`/`-mtune` in clang/gcc.
2013-08-10rustc: Add --target-cpu flag to select a more specific processor instead of ↵Luqman Aden-1/+2
the default, 'generic'.
2013-08-09Implement an `address_insignificant` attributeAlex Crichton-0/+5
This can be applied to statics and it will indicate that LLVM will attempt to merge the constant in .data with other statics. I have preliminarily applied this to all of the statics generated by the new `ifmt!` syntax extension. I compiled a file with 1000 calls to `ifmt!` and a separate file with 1000 calls to `fmt!` to compare the sizes, and the results were: fmt 310k ifmt (before) 529k ifmt (after) 202k This now means that ifmt! is both faster and smaller than fmt!, yay!
2013-08-04Fix build issues once LLVM has been upgradedAlex Crichton-10/+3
* LLVM now has a C interface to LLVMBuildAtomicRMW * The exception handling support for the JIT seems to have been dropped * Various interfaces have been added or headers have changed
2013-08-04Update LLVMAlex Crichton-1/+1
2013-07-28Add an atomic fence intrinsicJames Miller-1/+5
2013-07-21Avoid blocks for static allocas and loading the closure environmentBjörn Steinbrink-0/+1
These blocks were required because previously we could only insert instructions at the end of blocks, but we wanted to have all allocas in one place, so they can be collapse. But now we have "direct" access the the LLVM IR builder and can position it freely. This allows us to use the same trick that clang uses, which means that we insert a dummy "marker" instruction to identify the spot at which we want to insert allocas. We can then later position the IR builder at that spot and insert the alloca instruction, without any dedicated block. The block for loading the closure environment can now also go away, because the function context now provides the toplevel block, and the translation of the loading happens first, so that's good enough. Makes the LLVM IR a bit more readable, saving a bunch of branches in the unoptimized code, which benefits unoptimized builds.
2013-07-19debuginfo: Fixed some merge falloutMichael Woerister-0/+3
2013-07-19debuginfo: Support for tuple-style enums (WIP)Michael Woerister-42/+66
2013-07-19debuginfo: Added support for c-style enums.Michael Woerister-0/+30
2013-07-03force LLVM cleanDaniel Micay-1/+1
2013-07-01Turn on using LLVM threadsafelyAlex Crichton-0/+4
2013-06-27mk: add mechanisms for triggering clean-llvm builds from commitsGraydon Hoare-0/+0
2013-06-19rustc: Dispose of LLVM passes in test casesBrian Anderson-0/+6
2013-06-17Fixed rebase fallout .Vadim Chugunov-1/+3
2013-06-17Fixed remaining issues to pass debug-test/* tests.Vadim Chugunov-0/+12
Made debugger scripts source line insensitive.
2013-06-17Made the while DebugContext mutable, not just created_* hashesVadim Chugunov-34/+46
Disabled create_arg
2013-06-17Use DIBuilder in debuginfoVadim Chugunov-0/+220
2013-06-15auto merge of #7125 : alexcrichton/rust/rusti-issues, r=brsonbors-38/+39
This un-reverts the reverts of the rusti commits made awhile back. These were reverted for an LLVM failure in rustpkg. I believe that this is not a problem with these commits, but rather that rustc is being used in parallel for rustpkg tests (in-process). This is not working yet (almost! see #7011), so I serialized all the tests to run one after another. @brson, I'm mainly just guessing as to the cause of the LLVM failures in rustpkg tests. I'm confident that running tests in parallel is more likely to be the problem than those commits I made. Additionally, this fixes two recently reported issues with rusti.
2013-06-13Don't run passes again on JIT codeAlex Crichton-14/+0
These passes are already run beforehand, no need to do them twice.
2013-06-13Revert "Revert "Have JIT execution take ownership of the LLVMContextRef""Alex Crichton-19/+16
This reverts commit 19adece68b00bd1873499cca6f1537750608d769.
2013-06-13Revert "Revert "Remove all usage of the global LLVMContextRef""Alex Crichton-7/+25
This reverts commit 541c657a738006d78171aa261125a6a46f283b35.
2013-06-13automated whitespace fixesDaniel Micay-1/+0
2013-06-13Revert "Remove all usage of the global LLVMContextRef"Brian Anderson-25/+7
This reverts commit 779191cd4b8719e8efdf69fb6da93e2a8905ca1d. Conflicts: src/librustc/middle/trans/base.rs src/librustc/middle/trans/common.rs
2013-06-13Revert "Have JIT execution take ownership of the LLVMContextRef"Brian Anderson-16/+19
This reverts commit 5c5095d25e3652c434c8d4ec178e6844877e3c2d. Conflicts: src/librusti/rusti.rc
2013-06-10Have JIT execution take ownership of the LLVMContextRefAlex Crichton-19/+16
Also stop leaking the ExecutionEngine created for jit code by forcibly disposing of it after the JIT code has finished executing
2013-06-10Remove all usage of the global LLVMContextRefAlex Crichton-7/+25
This allows parallel usage of the rustc library
2013-05-29Further refactor optimization pass handlingJames Miller-216/+25
This refactors pass handling to use the argument names, so it can be used in a similar manner to `opt`. This may be slightly less efficient than the previous version, but it is much easier to maintain. It also adds in the ability to specify a custom pipeline on the command line, this overrides the normal passes, however. This should completely close #2396.
2013-05-29Remove extraneous defs from export fileJames Miller-3/+0
2013-05-29Refactor optimization pass handling.James Miller-45/+322
Refactor the optimization passes to explicitly use the passes. This commit just re-implements the same passes as were already being run. It also adds an option (behind `-Z`) to run the LLVM lint pass on the unoptimized IR.
2013-05-20rustllvm: Use target alignment for atomic load/storeBrian Anderson-6/+8
2013-05-17Fix AtomicLoad builder codeJames Miller-1/+1
2013-05-12Adds atomic_load, atomic_load_acq, atomic_store, and atomic_store_rel ↵Matthijs Hofstra-0/+24
intrinsics. The default versions (atomic_load and atomic_store) are sequentially consistent. The atomic_load_acq intrinsic acquires as described in [1]. The atomic_store_rel intrinsic releases as described in [1]. [1]: http://llvm.org/docs/Atomics.html
2013-05-03add gitattributes and fix whitespace issuesDaniel Micay-12/+11
2013-04-22Choose target featuresSeo Sanghyeon-1/+2
2013-04-19llvm: Fixes for RustWrapper.Patrick Walton-6/+0
2013-04-19rustllvm: Fix RustWrapper.cppPatrick Walton-7/+16
2013-04-19librustc: Implement fast-ffi and use it in various placesPatrick Walton-0/+1
2013-04-10rustllvm: Initialize target analysis passesBrian Anderson-1/+4
Without this the target info for certain optimizations will not be created and the compiler will sometimes crash
2013-04-10rustllvm: followup latest LLVMYoung-il Choi-9/+13
2013-04-05rustllvm: Only initialize command-line arguments onceTim Chevalier-4/+12
In my WIP on rustpkg, I was calling driver code that calls LLVMRustWriteOutputFile more than once. This was making LLVM unhappy, since that function has code that initializes the command-line options for LLVM, and I guess you can't do that more than once. So, check if they've already been initialized.
2013-03-19Enable arm error handling abi 2ILyoan-2/+3
2013-03-19Enable arm error handling abiILyoan-0/+5
2013-03-15Normalize target triple so that llvm can recognize target os correctlyILyoan-2/+2
2013-03-13Revamp foreign code not to consider the Rust modes. This requiresNiko Matsakis-2/+2
adjusting a few foreign functions that were declared with by-ref mode. This also allows us to remove by-val mode in the near future. With copy mode, though, we have to be careful because Rust will implicitly pass somethings by pointer but this may not be the C ABI rules. For example, rust will pass a struct Foo as a Foo*. So I added some code into the adapters to fix this (though the C ABI rules may put the pointer back, oh well). This patch also includes a lint mode for the use of by-ref mode in foreign functions as the semantics of this have changed.
2013-03-12Wrap llvm::InlineAsm::AsmDialectLuqman Aden-3/+3