[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

[Jim Grosbach]

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?
>
> 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.

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?

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.

-Jim