| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
migration away from LLVMAttribute"
This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7.
llvm-svn: 266259
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
away from LLVMAttribute
Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values.
Reviewers: Wallbraker, whitequark, joker.eph, echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18749
llvm-svn: 266257
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18820
llvm-svn: 265773
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. Patch
for Clang http://reviews.llvm.org/D15524
Differential Revision: http://reviews.llvm.org/D15525
llvm-svn: 265667
|
| |
|
|
|
|
|
|
| |
Patch by Nicole Mazzuca <npmazzuca@gmail.com>.
Differential Revision: http://reviews.llvm.org/D18729
llvm-svn: 265608
|
| |
|
|
|
|
|
|
| |
Patch by Nicole Mazzuca <npmazzuca@gmail.com>.
Differential Revision: http://reviews.llvm.org/D18736
llvm-svn: 265394
|
| |
|
|
| |
llvm-svn: 265353
|
| |
|
|
| |
llvm-svn: 265290
|
| |
|
|
| |
llvm-svn: 265277
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.
This commit does not include any target-specific change. The target-specific
optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
llvm-svn: 265189
|
| |
|
|
|
|
|
|
| |
This allows the linker to instruct ThinLTO to perform only the
optimization part or only the codegen part of the process.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265113
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17866
llvm-svn: 264754
|
| |
|
|
|
|
|
|
| |
minor fixes.
Differential revision: http://reviews.llvm.org/D18469
llvm-svn: 264598
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Also expose getters and setters in the C API, so that the change can be tested.
Reviewers: nhaehnle, axw, joker.eph
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18260
From: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
llvm-svn: 263886
|
| |
|
|
|
|
|
|
| |
Looks like I was sloppy when bridging to C.
Thanks D. Blaikie for noticing!
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263885
|
| |
|
|
| |
llvm-svn: 263349
|
| |
|
|
|
|
|
| |
Hopefully this should bring
llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast back to life.
llvm-svn: 262994
|
| |
|
|
|
|
|
| |
Remove a warning introduced in r262977
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is intended to provide a parallel (threaded) ThinLTO scheme
for linker plugin use through the libLTO C API.
The intent of this patch is to provide a first implementation as a
proof-of-concept and allows linker to start supporting ThinLTO by
definiing the libLTO C API. Some part of the libLTO API are left
unimplemented yet. Following patches will add support for these.
The current implementation can link all clang/llvm binaries.
Differential Revision: http://reviews.llvm.org/D17066
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 262977
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: It is not used.
Reviewers: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17251
llvm-svn: 262870
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API.
Reviewers: echristo, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17359
llvm-svn: 261254
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17245
llvm-svn: 261174
|
| |
|
|
| |
llvm-svn: 261172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This consist in variosu addition to the C API:
LLVMTargetDataRef LLVMGetModuleDataLayout(LLVMModuleRef M);
void LLVMSetModuleDataLayout(LLVMModuleRef M, LLVMTargetDataRef DL);
LLVMTargetDataRef LLVMCreateTargetMachineData(LLVMTargetMachineRef T);
Reviewers: joker.eph, Wallbraker, echristo
Subscribers: axw
Differential Revision: http://reviews.llvm.org/D17255
llvm-svn: 260936
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The name is confusing as it matche another method on the module.
Reviewers: joker.eph, Wallbraker, echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17283
llvm-svn: 260920
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: It's red, it's dead.
Reviewers: joker.eph, Wallbraker, echristo
Subscribers: llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D17282
llvm-svn: 260919
|
| |
|
|
| |
llvm-svn: 260916
|
| |
|
|
| |
llvm-svn: 260845
|
| |
|
|
| |
llvm-svn: 260720
|
| |
|
|
| |
llvm-svn: 260683
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This required to add binding to Instruction::removeFromParent so that instruction can be forward declared and then moved at the right place.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17057
llvm-svn: 260597
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. This also include extra support for insertvalue and extracvalue.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17055
llvm-svn: 260335
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instruction from the C API.
Summary: As per title. This remove the need to rely on internal knowledge of call and invoke instruction to find called value and argument count.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Differential Revision: http://reviews.llvm.org/D17054
llvm-svn: 260332
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Comes with an awesome test.
Depends on D16912
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16942
llvm-svn: 260313
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. Also add a facility method to get the name of a basic block from the C API.
Reviewers: bogner, chandlerc, echristo, dblaikie, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16912
llvm-svn: 260309
|
| |
|
|
| |
llvm-svn: 258937
|
| |
|
|
| |
llvm-svn: 258033
|
| |
|
|
| |
llvm-svn: 256107
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This deprecates:
* LLVMParseBitcode
* LLVMParseBitcodeInContext
* LLVMGetBitcodeModuleInContext
* LLVMGetBitcodeModule
They are replaced with the functions with a 2 suffix which do not record
a diagnostic.
llvm-svn: 256065
|
| |
|
|
| |
llvm-svn: 255981
|
| |
|
|
|
|
|
|
|
| |
Type specific declarations have been moved to Type.h and error handling
routines have been moved to ErrorHandling.h. Both are included in Core.h
so nothing should change for projects directly including the headers,
but transitive dependencies may be affected.
llvm-svn: 255965
|
| |
|
|
|
|
| |
These functions were deprecated in r97608.
llvm-svn: 255927
|
| |
|
|
|
|
|
| |
Passing in a std::unique_ptr should help find errors when the module
is used after being linked into another module.
llvm-svn: 255842
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that terminatepad gives little benefit over a cleanuppad
which calls the termination function. This is not sufficient to
implement fully generic filters but MSVC doesn't support them which
makes terminatepad a little over-designed.
Depends on D15478.
Differential Revision: http://reviews.llvm.org/D15479
llvm-svn: 255522
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When working with tokens, it is often the case that one has instructions
which consume a token and produce a new token. Currently, we have no
mechanism to represent an initial token state.
Instead, we can create a notional "empty token" by inventing a new
constant which captures the semantics we would like. This new constant
is called ConstantTokenNone and is written textually as "token none".
Differential Revision: http://reviews.llvm.org/D14581
llvm-svn: 252811
|
| |
|
|
|
|
|
|
| |
Fixed warnings are: modernize-use-override, modernize-use-nullptr and modernize-redundant-void-arg.
Differential revision: http://reviews.llvm.org/D14312
llvm-svn: 252087
|
| |
|
|
|
|
|
|
|
|
| |
and trampolines.""
This reverts commit r251937.
The test was updated to the new API, bring the API back.
llvm-svn: 251944
|
| |
|
|
|
|
|
|
|
|
| |
trampolines."
This reverts commit r251933.
It broke the build of examples/Kaleidoscope/Orc/fully_lazy/toy.cpp.
llvm-svn: 251937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bypassing LLVM for this has a number of benefits:
1) Laziness support becomes asm-syntax agnostic (previously lazy jitting didn't
work on Windows as the resolver block was in Darwin asm).
2) For cross-process JITs, it allows resolver blocks and trampolines to be
emitted directly in the target process, reducing cross process traffic.
3) It should be marginally faster.
llvm-svn: 251933
|