Displaying 20 results from an estimated 2000 matches similar to: "Way to guarantee generated indirect call is via memory?"
2013 Oct 23
2
[LLVMdev] GC StackMaps (was Stackmap and Patchpoint Intrinsic Proposal)
Hi all,
I don't know if I understand everything, but it seems really
interesting for a runtime developer, stackmap and patchpoint looks
perfect for a lot of optimizations :) I just have few question to
verify if I understand what are these stackmaps and patchpoints, and I
discuss the GC after.
* I have a first very simple scenario (useful in vmkit). Let's imagine
that we want to lazily
2013 Oct 22
4
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote:
> On 10/22/13 10:34 AM, Filip Pizlo wrote:
>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote:
>>
>>> On 10/17/13 10:39 PM, Andrew Trick wrote:
>>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
>>>> first client
2015 Jul 23
2
[LLVMdev] ORC and relocations
Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations.
I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames.
I understand that
2015 Jul 24
0
[LLVMdev] ORC and relocations
Hi Eugene,
Sorry for the delayed reply. Custom relocations weren't something I had in
mind when I designed Orc, so they raise some interesting design questions
which I don't have good answers to yet. (E.g. The interface for the Orc
layer concept assumes that there's a RuntimeDyld instance embedded at the
bottom of the stack. That's why addModuleSet takes a MemoryManager and
2013 Oct 22
2
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote:
> On 10/17/13 10:39 PM, Andrew Trick wrote:
>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
>> first client of these features is the JavaScript compiler within the
>> open source WebKit project.
>>
> I have a couple of comments on your proposal. None of these
2013 Oct 22
0
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote:
>
>> On 10/22/13 10:34 AM, Filip Pizlo wrote:
>>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote:
>>>
>>>> On 10/17/13 10:39 PM, Andrew Trick wrote:
2015 Jul 23
2
[LLVMdev] ORC and relocations
Hi Lang,
It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below.
The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer.
I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and
2015 Jul 23
0
[LLVMdev] ORC and relocations
Hi Eugene,
Skipping the call to resolveRelocations would disable many (if not all)
internal relocations too. Is that the desired behavior?
At that point there's not much left for RuntimeDyld (or the
ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a
workable solution?
Cheers,
Lang.
On Wed, Jul 22, 2015 at 7:26 PM, Eugene Rozenfeld <
Eugene.Rozenfeld at
2015 Jun 30
2
[LLVMdev] ORC and relocations
Hi Lang,
Yes, I can return a non-zero marker value. Are you ok with this version?
void RuntimeDyldImpl::resolveExternalSymbols() {
while (!ExternalSymbolRelocations.empty()) {
StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin();
StringRef Name = i->first();
if (Name.size() == 0) {
// This is an absolute symbol, use an address of zero.
2015 Jun 26
2
[LLVMdev] ORC and relocations
Hi Lang,
Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me:
void RuntimeDyldImpl::resolveExternalSymbols() {
while (!ExternalSymbolRelocations.empty()) {
StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin();
StringRef
2013 Oct 23
0
[LLVMdev] GC StackMaps (was Stackmap and Patchpoint Intrinsic Proposal)
I'm moving this to a different thread. I think the newly proposed
intrinsic definitions and their current implementation are valuable
regardless of how it gets tied into GC...
On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote:
> Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support
2013 Oct 22
0
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On 10/17/13 10:39 PM, Andrew Trick wrote:
> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
> first client of these features is the JavaScript compiler within the
> open source WebKit project.
>
I have a couple of comments on your proposal. None of these are major
enough to prevent submission.
- As others have said, I'd prefer an experimental namespace
2015 Jul 23
2
[LLVMdev] LoadedObjectInfo::getSectionLoadAddress
Hi Lang,
LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That breaks if the object file has multiple sections with the same name. I made a change to add an overload that takes a SectionRef&. Can you please take a look?
https://github.com/erozenfeld/llvm/commit/65f635e426bdc8e80a29ed370a78f0c0a282f265
Thanks,
Eugene
-------------- next part --------------
An HTML
2015 Jun 24
3
[LLVMdev] ORC and relocations
Hello,
I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of
2013 Oct 22
0
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
On 10/22/13 10:34 AM, Filip Pizlo wrote:
> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote:
>
>> On 10/17/13 10:39 PM, Andrew Trick wrote:
>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
>>> first client of these features is the JavaScript compiler within the
>>> open source WebKit project.
2013 Oct 23
5
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
Adding Gael as someone who has previously discussed vmkit topics on the
list. Since I'm assuming this is where the GC support came from, I
wanted to draw this conversation to the attention of someone more
familiar with the LLVM implementation than myself.
On 10/22/13 4:18 PM, Andrew Trick wrote:
> On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com
> <mailto:fpizlo
2014 Oct 14
2
[LLVMdev] Thoughts on maintaining liveness information for stackmaps
I think what's happening is BranchFolder::MaintainLiveIns is using a
forward analysis on top of these missing kill flags, and updating the
BB-live-ins/live-outs with an incorrect set of registers. Then when the
stackmaps liveness analysis happens, it's not doing anything wrong, but it
starts with the wrong set of live registers and will propagate those to the
point of the
2014 Feb 26
5
[LLVMdev] Representing a safepoint as an instruction in the x86 backend?
I've got a pseudo instruction with some tricky semantics I need help
figuring out how to encode properly. For those interested, this is to
support fully relocating garbage collection. I'm going to try to
express the requirements clearly so that you don't need to understand
the use case in detail.
My end goal is to capture a list of registers and/or stack offsets for a
list of
2015 Jul 23
0
[LLVMdev] LoadedObjectInfo::getSectionLoadAddress
On Wed, Jul 22, 2015 at 9:41 PM, Eugene Rozenfeld
<Eugene.Rozenfeld at microsoft.com> wrote:
> Hi Lang,
>
>
>
> LoadedObjectInfo::getSectionLoadAddress takes StringRef as an arg. That
> breaks if the object file has multiple sections with the same name. I made a
> change to add an overload that takes a SectionRef&. Can you please take a
> look?
>
>
>
2013 Oct 18
5
[LLVMdev] [RFC] Stackmap and Patchpoint Intrinsic Proposal
This is a proposal for adding Stackmaps and Patchpoints to LLVM. The
first client of these features is the JavaScript compiler within the
open source WebKit project.
A Stackmap is a record of variable locations (registers and stack
offsets) at a particular instruction address.
A Patchpoint is an instruction address at which space is reserved for
patching a new instruction sequence at runtime.