| Age | Commit message (Collapse) | Author |
|---|
|
I just tried to copy what was done for regular InstCombine. Hopefully I didn't miss anything.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330668 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule
They are replaced with the functions with a 2 suffix which do not record
a diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256065 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
folding the code into the main Analysis library.
There already wasn't much of a distinction between Analysis and IPA.
A number of the passes in Analysis are actually IPA passes, and there
doesn't seem to be any advantage to separating them.
Moreover, it makes it hard to have interactions between analyses that
are both local and interprocedural. In trying to make the Alias Analysis
infrastructure work with the new pass manager, it becomes particularly
awkward to navigate this split.
I've tried to find all the places where we referenced this, but I may
have missed some. I have also adjusted the C API to continue to be
equivalently functional after this change.
Differential Revision: http://reviews.llvm.org/D12075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245318 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Originally added in r139314.
Back then it didn't actually get the address, it got whatever value the
relocation used: address or offset.
The values in different object formats are:
* MachO: Always an offset.
* COFF: Always an address, but when talking about the virtual address of
sections it says: "for simplicity, compilers should set this to zero".
* ELF: An offset for .o files and and address for .so files. In the case of the
.so, the relocation in not linked to any section (sh_info is 0). We can't
really compute an offset.
Some API mappings would be:
* Use getAddress for everything. It would be quite cumbersome. To compute the
address elf has to follow sh_info, which can be corrupted and therefore the
method has to return an ErrorOr. The address of the section is also the same
for every relocation in a section, so we shouldn't have to check the error
and fetch the value for every relocation.
* Use a getValue and make it up to the user to know what it is getting.
* Use a getOffset and:
* Assert for dynamic ELF objects. That is a very peculiar case and it is
probably fair to ask any tool that wants to support it to use ELF.h. The
only tool we have that reads those (llvm-readobj) already does that. The
only other use case I can think of is a dynamic linker.
* Check that COFF .obj files have sections with zero virtual address spaces. If
it turns out that some assembler/compiler produces these, we can change
COFFObjectFile::getRelocationOffset to subtract it. Given COFF format,
this can be done without the need for ErrorOr.
The getRelocationAddress method was never implemented for COFF. It also
had exactly one use in a very peculiar case: a shortcut for adding the
section value to a pcrel reloc on MachO.
Given that, I don't expect that there is any use out there of the C API. If
that is not the case, let me know and I will add it back with the implementation
inlined and do a proper deprecation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241450 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The returnvalue was handled as c_char_p which ment that ctypes
handled it as a NUL-terminated string making it cut the contents
at first NUL (or even worse - overrunning the buffer if it doesn't
contain a NUL).
Differential Revision: http://reviews.llvm.org/D3474
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Broke after the changes related to the LLVMGetSymbolFileOffset
removal in r206750
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207018 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
We normally don't drop functions from the C API's, but in this case I think we
can:
* The old implementation of getFileOffset was fairly broken
* The introduction of LLVMGetSymbolFileOffset was itself a C api breaking
change as it removed LLVMGetSymbolOffset.
* It is an incredibly specialized use case. The only reason MCJIT needs it is
because of its odd position of being a dynamic linker of .o files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also fixed some trailing whitespace issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201929 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Check should be for pointer being NULL, not what it points to.
Also adds a test for this case.
Reviewed By: indygreg
Differential Revision: http://llvm-reviews.chandlerc.com/D1878
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194965 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
As the "LLVMInitializeAll*" functions are not available as symbols in
the shared library they can't be used, and as a workaround a list of
the targets is kept and the individual symbols tried. As soon as the
"All"-functions are changed to proper symbols (as opposed to static
inlines in the headers) this hack will be replace with simple calls
to the corresponding "LLVMInitializeAll*" functions.
Reviewed By: indygreg
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1879
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
getting the number of operands of a value.
Also in the process did some cleanups for BasicBlock.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190477 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instructions, getting their name/dumping them, f/b iteration.
Tests are included.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
blocks, dumping/getting names of those bb, f/w iteration.
Tests are included.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190473 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
f/b over said functions, dumping/print name of functions.
Tests are included as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190471 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190468 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190459 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
datalayout, getset its target, dump it, print it to a file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a new context or getting the global context.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190457 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initialize/shutdown llvm. Also included an initialize_llvm declaration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190456 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190455 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the generic provided test_file instead of a binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190389 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
included.
This is a part of a series of patches that have been sitting fallow on a
personal branch that I have been messing with for a bit.
The patches start to flesh out the python llvm-c wrapper to the point where you can:
1. Load Modules from Bitcode/Dump/Print them.
2. Iterate over Functions from those modules/get their names/dump them.
3. Iterate over the BasicBlocks from said function/get the BB's name/dump it.
4. Iterate over the Instructions in said BasicBlocks/get the instructions
name/dump the instruction.
My main interest in developing this was to be able to gather statistics about
LLVM IR using python scripts to speed up statistical profiling of different IR
level transformations (hence the focus on printing/dumping/getting names).
This is a gift from me to the LLVM community = ).
I am going to be committing the patches slowly over the next bit as I have time
to prepare the patches.
The overall organization follows the c-api like the bindings that are already
implemented.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190388 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181350 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch contributed by Wladimir J. van der Laan <laanwj@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169102 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Before this fix, the LLVM Python bindings on SVN trunk always fail with:
Exception: LLVM shared library not found!
since it's still looking for a library named "LLVM-3.1svn".
Besides updating the LLVM version in the library name,
this patch also changes llvm.get_library() to make it possible to run
the unit tests without installing the LLVM shared library into a
default linker search path.
e.g. after this patch, running the llvm/python unit tests with:
LD_LIBRARY_PATH=../build/Debug+Asserts/lib nosetests -v bindings/python/llvm/tests/
would work on Linux.
Patch from Scott Tsai (with some minor modifications)
Patch also acked by Gregory Szorc
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168390 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153248 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Adds /usr/lib/debug early to list, as some systems (debian) have unstripped libs in there
Adds /lib/i386-linux-gnu for systems that does multiarch (debian)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153174 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
get_test_binary is a helper method, not a test, make sure nosetests
doesn't pick it up as a test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It doesn't currently support the op info and symbol lookup callbacks,
but it is better than nothing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152527 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Chris Lattner says the edis interface is going away. It doesn't make
sense to land something that will go away in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152508 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This requires a C++ change to EDDisassembler's ctor to function properly
(the llvm::InitializeAll* functions aren't being called currently and
there is no way to call them from Python).
Code is partially tested and works well enough for initial commit. There
are probably many small bugs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152506 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152505 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152483 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is now possible to load object files and scan over sections, symbols,
and relocations! Includes test code with partial coverage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152482 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previous code had a double free in MemoryBuffer. The tests now pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152422 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This contains a semi-functional skeleton for the implementation of the
LLVM bindings for Python.
The API for the Object.h interface is roughly designed but not
implemented. MemoryBufferRef is implemented and actually appears to
work!
The ObjectFile unit test fails with a segmentation fault because the
LLVM library isn't being properly initialized. The build system doesn't
know about this code yet, so no alerts should fire.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152397 91177308-0d34-0410-b5e6-96231b3b80d8
|
