[llvm-commits] [llvm] r57846 - in /llvm/trunk: include/llvm/System/Memory.h lib/System/Unix/Memory.inc lib/System/Win32/Memory.inc lib/Target/ARM/ARMJITInfo.cpp

Evan Cheng evan.cheng at apple.com
Tue Oct 21 09:24:30 PDT 2008


On Oct 21, 2008, at 8:22 AM, Jim Grosbach wrote:

>
> On Oct 20, 2008, at 10:42 PM, Evan Cheng wrote:
>
>>
>> On Oct 20, 2008, at 2:39 PM, Jim Grosbach wrote:
>>
>> Thanks Jim. Good job getting this working. It's a big step.
>>
>>>
>>> +    // Save caller saved registers since they may contain stuff
>>> +    // for the real target function right now. We have to act as if
>>> this
>>> +    // whole compilation callback doesn't exist as far as the
>>> caller is
>>> +    // concerned, so we can't just preserve the callee saved regs.
>>> +    "push {r0, r1, r2, r3, lr}\n"
>>
>> Is this code Mac OS X specific? Is "push" accepted by all the
>> assemblers?
>>
>
> It's standard, but relatively recent (sometime in the last few years,
> depending on toolchain) for the mnemonic to be recognized in ARM
> state. How concerned are we about older assemblers?

I think we should use mnemonic that are as widely accepted as  
possible. I believe the original author did test the callback routine  
on his target. We should be careful not to break it.

>
>>
>> This works. But it's probably somewhat inefficient. Do you have any
>> ideas for improving the efficiency? I have some ideas, we should talk
>> about it.
>
>
> A bit. Not a huge amount, though. At this point, I was mainly just
> focused on correctness. That said, there's a few things I've been
> tossing around in the back of my head. I'd love to hear any ideas you
> have as well. There's a strange constant pool thing I was hoping to
> find time to bounce off of you today, anyway, so we can kill two birds
> with one conversation.

Sure.

>
>
> I haven't been very concerned about making the compilation hooks all
> that efficient, really. Any time spent there is going to be so swamped
> by the compilation (or probably even just the function address
> lookup), that it didn't seem worth it, at least in a first pass. Seem
> reasonable to you?

Right. I am not too concerned with getting it perfect at this point.  
It's definitely not a critical task. That said, this is something we  
should plan on cleaning up later. I am actually more concerned with  
"cleanliness"  than anything else. Having the stub making a system  
call to change memory privilege just seem icky to me. My basic idea is  
to allocate a chunk RX memory for code (like what's being done now)  
and a chunk of RW memory for data and anything that's going to be  
changed during execution (i.e. putting addresses of lazily compiled  
functions there). This will require a larger scale rewrite so it's not  
something that should be planned for the near future.

>
>
> Where I want things to be relatively quick is in subsequent
> invocations, which is why I re-write the stub to be just an indirect
> branch. The tweak I'd like to make there is to check the range of the
> branch and use a direct branch instruction instead if possible. We
> know both addresses, after all, so there's no unknowns we have to be
> pessimistic about. Similarly, I'm thinking about putting in some logic
> to go all the way back to the original call point and adjusting the
> call instruction there, if it's a direct branch.

Sounds good.

Evan
>
>
> -Jim
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list